On Tue, Dec 07, 2021 at 12:03:04PM -0600, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> said: > > The second case is when the admin has actually > > locked down the kernel command line and relies on the normal > > authentication mechanisms to protect the system. In both cases your > > proposal creates an additional method of attack that activates at a > > later point where the system is already running and the integrity of > > the system must be maintained to protect unencrypted data. With the > > proposal, any mechanism which leads to the system entering emergency > > mode results in a compromise. > > If the admin has done one thing to lock down the system, then they can > do another (removing the sulogin --force addition). Right now, Fedora > is shipping an inconsistent (and frustrating) state: one part is locked > down, but another is not (so the first can be bypassed, in an annoying > way). Prompting for a root password at rescue/emergency mode is not > security in the default config and so should not be done (at least when > no such password is set, as some of the default Fedora configs have). I agree that prompting for an unset root password is annoying: we should just say upfront that the login is not possible that way. But I don't agree that we should punch an new hole just because a different one exists. The existing shortcomings are well known, and can be worked around, and are not relevant in all circumstances. The new mechanism opens the system from a different side. I also don't think we should assume that the admin will do a series of "hardening steps". This is what we had in the 90's: you'd install a stock distro and then go over a checklist of basic steps to make things secure. Let's not go back to that. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
