On Tue, Dec 07, 2021 at 12:03:04PM -0600, Chris Adams wrote:
Once upon a time, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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).
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