Re: patch for 2.1.84: configurable execute_program--testers needed

James Mastros (root@jennifer-unix.dyn.ml.org)
Sun, 1 Feb 1998 10:27:09 -0500 (EST)


On Sun, 1 Feb 1998, Trevor Johnson wrote:
> > > With the stock kernel, the feature is enabled whether the user
> > > wants it (or knows it exists) or not. Calling this "insecurity through
> > > obscurity" would not be a great exaggeration.
> > Not really. Disabling the init= option dosn't make the system much more
> > secure.
>
> The init= option is not completely disabled. You can still use it to pass
> parameters to init (init=single for example).
This has SECURITY RISK written all over it. Then again, allowing ANYTHING
on the kernel command line has security risk written all over it. But most
of all, allowing the machine to be rebooted in the first place...

Yank the reset button jumper from the mobo, and have init ignore
control-alt-delete. The point becomes moot, as only root can reboot, and
then he can just stay at the console until the machine is back in multiuser
mode.

> Using "init=/bin/sh"
> however will not get you a root shell, if you choose to say "no" to the
> option.
But hitting control-c during single-user mode will (unless your init goes
into raw keybord mode, which is doable, but by no means obvious...). My
point is that this patch is trivial to get around, and if you know how to
pass init= to the kernel in the first place, then you probably can figgure
out many other things to do. The best protetiction of the boot-process is
for it not to occour while untrusted persons are about.

> Because of your remarks, I've revised the patch to make this more
> clear, and I've mentioned the hazards of bootable removable media. The
> current patch is at:
>
> http://jpj.net/~trevor/linux/execute_command-v3-2.1.84.diff
It looks nice, very clean.

> Thanks also to Michael Chastain for suggesting a default of Y for this,
> and to Jon Lewis for pointing out LILO's password feature. I've used
> their suggestions in the current version.
I would suguest that you ask for intergration shortly (assuming some
testing. Not is much needed, as this patch is very cut-and-dry)... It's not
that it dosn't help security, but it is hardly a be-all and do-all. There
are many other ways of getting root with a booting system. (A patch to
ignore control-alt-delete from the get-go would help -- posibly only with a
boot-option that defaults to off. The best security is keeping tight spots
from occouring (without restricting useful functionality).)

> > You could, for example, put in a floppy with a root, and set root=.
>
> I suggest CONFIG_BLK_DEV_FD=m for such a setup. Yes, someone could spray
> saltwater into your floppy drive, or use other boot commands to cause
> havoc. This patch doesn't try to change that; it is just meant to make a
> small part of the kernel configurable rather than mandatory.

A good thing, I just mention that using it as security is a fuitule attempt.
If you can get to the commandline in the first place, you can almost
definitly get root.

-=- James Mastros