Any user can reboot a red hat linux system and type "linux
single" at the lilo prompt and come with a root shell in
single user mode. It is then a simple task to just edit
/etc/shadow to change the root password, or, even worse,
create a new user with a uid of zero. Then they reboot the
system and security has been compromised.
Now, one can say this is not a bug, because you can't
protect a machine from someone with physical access. I.e.
Anyone can get in with a bootdisk, or if booting from a
disk is disabled in the bios, then they just swapp the hard
drive to another system and mount it.
However, in the initscripts where the filesystems are
mounted and checked, care is taken to not bump out to a
root shell without asking for the root password. (See where
/etc/rc.d/rc.sysinit calls sulogin.)
But I think the better argument that this security hole is
way too easy to use. This could get around to users who
might have fun saying, "look at me hack your Linux desktop
in two min flat without any real tools."
This is just the thing that could by hyped by some annoying
media outlet like ZD-Net as a "new major security hole in
linux". Just as the limit on the number of processes
running and the fact that anyone can force init to create
new processes was discovered as "the fatal UNIX design
flaw." (If you can't tell, I don't like them too much. he
And, as Linux machines become desktop machines instead of
server locked away in closets where physical access is more
closely guarded, this security hole becomes more of a
What about the solution? Well, I have a few thoughts.
One solution is to place a password on boot parameters in
this /etc/lilo.conf file. However, this is annoying because
it's not tied into the root password. But perhaps there is
some way to tie it in. I've done this to secure systems.
Another solution is to modify the mechanism that starts
that root shell to actually call suroot like rc.sysinit
does. I don't know if this in the kernel or some conf file;
it's been a long time since I poked around there.
But hey, the kernel can exec /sbin/sulogin just as easily
as /bin/sh. You could even make it look for
/sbin/singleusershell, then /bin/sh.. and just make
/bin/singleusershell a symlink to /sbin/sulogin. This is
nicely reverse compatible and customizable. I like it.
(I posted this as a bug to the lilo package, because I
could not think of a better package. Also, I think this is
only an i386 problem because lilo is arch specific, but it
might be on others. I simply don't know.)
Unfortunately, without a lilo password, you can do the
exact same thing with 'linux init=/bin/bash'. Hence,
fixing one without the other is sort of pointless, and
we can't take the 'init' functionality out of lilo. We
may look at passwording lilo in the future.
A line is missing in /etc/inittab of the RedHat distributions.
If you add "~~:S:wait:/sbin/sulogin" on a line by itself in
/etc/inittab, then you will be prompted for the root password
when entering single mode.
Hum... I think you are right here, I forgot that the kernel still
runs init when it enters single user mode.
I'd really love to get this fix in the next Red Hat release. IMO,
even though the init=/bin/bash backdoor still exists, getting ride of
the single user mode boot backdoor makes the system more secure,
because it is much more easy to stumble into. I.e. lots of people
know about single user mode... it's a UNIX standard. And I'll bet
more than a handful have booted to single user mode then thought
"Hey! Why was I not prompted for a password!?" Less people probably
have read the boot prompt HOWTO and remember the init= option.