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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org