Small security option

Small security option

[John R Moser]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 367 bytes --]

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.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 3098 bytes --]

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
 }

Re: Small security option

[Rene Rebe]

Hi,

On: Wed, 17 Sep 2003 20:55:44 -0400 (EDT),
    John R Moser <jmoser5@student.ccbc.cc.md.us> 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
  rene@rocklinux.org rene@rocklinux-consulting.de
http://www.rocklinux.org http://www.rocklinux-consulting.de
http://gsmp.tfh-berlin.de/gsmp http://gsmp.tfh-berlin.de/rene

Re: Small security option

[Mitchell Blank Jr]

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

Re: Small security option

[Chris Wright]

* John R Moser (jmoser5@student.ccbc.cc.md.us) 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

Re: Small security option

[bert hubert]

On Wed, Sep 17, 2003 at 06:25:43PM -0700, Chris Wright wrote:
> * John R Moser (jmoser5@student.ccbc.cc.md.us) 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

Re: Small security option

[Richard B. Johnson]

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.