Quoting Tom Diehl <tdiehl@xxxxxxxxxxxx>: > Well, I will admit I had not thought of that case. :-) In that case they can > still play with grub and bypass the root passwd at boot time, so how does > that help? > > I am sure we could argue different corner cases on this forever. :-) I hope > you will agree this is a corner case though. Since there are likely to be multiple such cases, why discount them? > How does a grub passwd not solve the problem. As someone else already > mentioned > if you can modify the bootloader you can run init=/bin/sh from the grub > command > line and bypass the passwd checks anyway. If you want to limit the discussion to only machines running grub, then the argument becomes somewhat easier. But maybe some people want the docs to pertain to alternative boot loaders also? Maybe not... I don't know the scope of the doc myself. But, there is of course always the defense in depth argument. Always use as many layers of defense as you can. Say they manage to somehow know your grub password (they watched you type it, it was easy to guess, they used to be an employee of yours and you didn't change it since they left, etc). But if they don't also know the root password, then the defense in depth strategy stops them. Your strategy (rely only on grub) does not stop them. > But in a data center environment you already control who is sitting in front > of the console. No, you don't. Someone can come in (janitor, repair man, someone who was able to social-engineer his way in, someone who broke in, etc) who isn't supposed to. And can you really trust all your employees anyway? > If you do not then you have other problems. We all have problems... > My whole point to this goes back to the original concept of "If you have > physical access to the machine it is not secure" I will argue that a grub My whole point is we can make it as secure as possible by using the security in depth principal, to cover all cases. Sometimes (a university computer lab) we let people have physical access to the machine, but we still want to keep them from playing with it as root, to the best extent possible. So, we disable the power button, put on a bios password, disable booting from external media, put a grub/lilo/milo/etc. password on, put a single user password on, put an alarm on the system that prevents opening the case without the alarm going off, etc. Now, what if you *forget* to do one of those? Don't you want a backup to be there? I'm not perfect, and it is possible someday I might make a mistake and accidently leave one of the above security features disabled after working on a machine. I'd like to think that I've got additional backup security methods in place to help protect me even if I do mess up one of them. (yeah, if I mess up too many, I'm hosed, but...) > passwd does more to protect from the casual user trying to gain root access, > than requiring a passwd for RL-1. It is just too easy to bypass. If as others > have argued the would be cracker only has access to the console but no access > to the physical machine then a grub passwd or simply disabling > <ctrl><alt><del> > is the way to go. But what if an upgrade, or a new admin who doesn't know better, accidently enables <ctrl><alt><del> on it? What then? > If they can't reboot it they will never see grub to play > with > it. Uhm, what if they just pull the power cord? Or trip the breaker? Or find a way to short it out. Or there is a power outage in the building. Or... > Regards, > > Tom Diehl tdiehl@xxxxxxxxxxxx Spamtrap address mtd123@xxxxxxxxxxxx -- Eric Rostetter -- fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
