Once upon a time, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 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). Fedora should ship in a consistent state, and this is the most straight-forward way of getting there. Locking down a system beyond the default requires changing a bunch of things, so I do not see adding this to that list to be a problem. -- Chris Adams <li...@cmadams.net> _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
