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
}
Hi,
On: Wed, 17 Sep 2003 20:55:44 -0400 (EDT),
John R Moser <[email protected]> wrote:
> 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.
+ 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.
Erhm this adds no security - you know most people always have a USB
stick or Credit Card CD with a tiny Linux in the pocket? Or just take
the HD out of your box?
Maybe you should configure GRUB to need a password to change the
config on-the-fly to gain the same amount of "security"?
> The file is attatched.
Sincerely yours,
Ren? Rebe
--
Ren? Rebe - Europe/Germany/Berlin
[email protected] [email protected]
http://www.rocklinux.org http://www.rocklinux-consulting.de
http://gsmp.tfh-berlin.de/gsmp http://gsmp.tfh-berlin.de/rene
John R Moser wrote:
> 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.
1. If you have physical access to the machine you're screwed anyway (boot
from a CD... if BIOS is password-protected just temporarily put the
harddrive in another machine)
2. In the relatively rare cases that you have physical access to the console
but not the machine (locked down kiosks or secured lab settings) you can
(and should) secure the bootloader. This prevents any malicious command
line options (think "root=my.nfs.server:/toolkit") not just "init=".
So this patch is basically pointless.
-Mitch
* John R Moser ([email protected]) wrote:
> 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.
If you have this access, you already own the box.
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Wed, Sep 17, 2003 at 06:25:43PM -0700, Chris Wright wrote:
> * John R Moser ([email protected]) wrote:
> > 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.
>
> If you have this access, you already own the box.
> -chris
Not *entirely* true. I know of hardware that would scream if it were opened
and refuse to boot the next time, unless a bios password would be entered.
Sure, it can be circumvented, but allowing software to bypass such measures
seems silly.
However, in this case, lilo or grub or whatever should prevent the user from
entering kernel parameters if they aren't authorized, not the kernel.
Bert.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
On Wed, 17 Sep 2003, John R Moser wrote:
> 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.
No. I can still boot your box, mount your root file-system, and
change the root password, all without you even knowing it.
If I have physical control of a computer, I own it. I can
do anything I want with it. If you could really prevent
somebody from "breaking in", then you can never sell it and
you are screwed if the password file gets corrupt (you would have
to throw everything away).
This patch is not useful.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.