Messages in this thread Patch in this message | | | Date | Wed, 17 Sep 2003 20:55:44 -0400 (EDT) | From | John R Moser <> | Subject | Small security option |
| |
Why wasn't this done in the first place anyway?
Some sysadmins like to disable the other boot devices and password-protect the bios. Good, but if the person can pass init=, you're screwed.
Here's a small patch that does a very simple thing: Disables "init=" and using /bin/sh for init. That'll stop people from rooting the box from grub.
The file is attatched.diff -ur linux-2.4.22/Documentation/Configure.help linux-2.4.22-secureinit/Documentation/Configure.help --- linux-2.4.22/Documentation/Configure.help 2003-08-25 07:44:39.000000000 -0400 +++ linux-2.4.22-secureinit/Documentation/Configure.help 2003-09-17 20:38:19.000000000 -0400 @@ -2529,6 +2529,32 @@ behaviour is platform-dependent, but normally the flash frequency is a hyperbolic function of the 5-minute load average. +Secure init +CONFIG_SECURE_INIT + Under normal circumstances, the kernel tries the following at boot + as init: + + /sbin/init + /etc/init + /bin/init + /bin/sh + + This can be overridden by passing init= to the kernel command line. + This is a security hazard. If you say 'Y' here, init= will be + ignored (actually it will flash a warning at boot time), and /bin/sh + will also never be used as init. This prevents users with physical + access to the machine from gaining root access by passing + init=/bin/bash to the kernel. + + It is common to pass init=/bin/bash to the kernel to fix really + messed up machines. If you say 'Y' here, you should make sure you + have a boot floppy with a kernel compiled with normal init code, OR + a rescue system such as a boot/root floppy or a Knoppix CD. + + Most users should say 'Y' here, unless you know you will not have + access to alternate recovery methods as listed in the above + paragraph. + Networking support CONFIG_NET Unless you really know what you are doing, you should say Y here. diff -ur linux-2.4.22/arch/i386/config.in linux-2.4.22-secureinit/arch/i386/config.in --- linux-2.4.22/arch/i386/config.in 2003-08-25 07:44:39.000000000 -0400 +++ linux-2.4.22-secureinit/arch/i386/config.in 2003-09-17 20:39:58.000000000 -0400 @@ -261,6 +261,7 @@ mainmenu_option next_comment comment 'General setup' +bool 'Secure init' CONFIG_SECURE_INIT bool 'Networking support' CONFIG_NET # Visual Workstation support is utterly broken. diff -ur linux-2.4.22/init/main.c linux-2.4.22-secureinit/init/main.c --- linux-2.4.22/init/main.c 2003-08-25 07:44:44.000000000 -0400 +++ linux-2.4.22-secureinit/init/main.c 2003-09-17 20:35:59.000000000 -0400 @@ -574,11 +574,28 @@ * trying to recover a really broken machine. */ + /* + * init= is a security hazzard. Let's configure it out. + */ + if (execute_command) +#ifndef CONFIG_SECURE_INIT execve(execute_command,argv_init,envp_init); +#else + { + printk("WARNING: kernel parameter: {init="); + printk(execute_command); + printk("} passed, but CONFIG_SECURE_INIT set. init= parameter IGNORED\n"); + } +#endif execve("/sbin/init",argv_init,envp_init); execve("/etc/init",argv_init,envp_init); execve("/bin/init",argv_init,envp_init); +#ifndef CONFIG_SECURE_INIT execve("/bin/sh",argv_init,envp_init); panic("No init found. Try passing init= option to kernel."); +#else + printk("CONFIG_SECURE_INIT defined, and init not found.\n"); + panic("No init found. Init must be in /sbin/init, /etc/init, or /bin/init"); +#endif } | |