[Pkg-sysvinit-devel] Bug#517018: responses to no-root login bug

[Michael S. Gilbert]

Wouter Verhelst wrote:
> There are several ways in which a local attacker can get root access.
> 'init=/bin/bash'. boot with the 'emergency' option (which causes
> sysvinit to do almost the same thing as 'init=/bin/bash'). Boot a
> live-CD, chroot into the target system. Worst case, remove the disk from
> the system, put it in a different machine, and chroot from there.

it's one thing to be able to gain root via hardware-assisted methods,
which users can take actions to make harder.  the key is that
hardware-assisted attacks look pretty suspicious and you would have a
better chance of detecting the attacker (you would notice the cd or
flash drive, and it would look odd; it would require the attacker to
crack open the machine to enable boot from media if the user has
inteligently set the boot sequence, which takes time and looks very
suspicious; and its definately obvious that you've been attacked if your
hard drive is completely missing).  its another thing for an attacker to
come in cold and surrepticiously own the machine in under 10 seconds.

for example, you leave your machine with screen lock on in a coffee
shop, while you go to the restroom.  when you come back two minutes
later you see that its back at the login screen, which looks strange,
but you think "oh well, it must have been a power surge."  too bad it
only took the attacker 10 seconds to compromise the machine.

Jérémy Bobbio wrote: 
> I don't see this as a bug at all.  The debian-installer can configure
> GRUB passwords and hard disk encryption.  The later being a really
> effective measure again the threat you describe.

these are great features, but in order for them to be effective they
need to be set up as the defaults so that your average users (>90%) are
protected.  debian should be "secure by default."

so i think a couple things need to happen to sufficiently address this
issue (and to consequently protect average users):

1.  set up a grub password, by default, during installation (this
prevents unauthorized users from using the 'init' option while
also allowing authorized users to do so for recovery purposes)
2.  fix sysvinit to always require a valid password (this prevents
unauthorized users from using the built-in "single" boot option for
malicious purposes)

obviously it's still up to the owner to prevent boot from media and to
take any other necessary hardening precautions to prevent other
hardware-assisted scenarios.

thank you for your consideration,
mike