Bug#806852: Why hasn't the "sulogin --force" patch been merged yet?

[Stijn van Drongelen]

Hi everyone,

Today, I was fiddling around a bit with nVidia drivers. I was fed up
with the constant screen tearing, and decided to try fixing it once more.
In the end, I hit a fatal bug in nvidia_drm that triggers when X starts.

This taught me two things:

1) I really should back up more often.
2) I really should understand solutions before applying them.

I could recover my system, if only I could prevent X from loading before
I can revert the settings by moving and deleting some files. I rebooted
and tried starting the rescue mode.

This taught me two things:

3) The behaviour described in this bugreport exists.
4) The people responsible for resolving this bug are avoiding any kind
   of honest security analysis.

Let's assume for a second that the Debian installer offers the option
to password-protect GRUB. When configured properly, this prevents an
unauthenticated user from opening the console, editing options, and
from starting specific boot variants (such as rescue mode; see [1]).
The fact that the Debian installer doesn't offer this option is IMO
not merely something that warrants a feature request, but a huge glaring
security problem.

Let's also assume that, whoever installed the system, had the knowledge
and forethought to lock down any options in the BIOS that would allow
anyone from booting anything else than that password-protected GRUB.

That should match Michael Biebl's example scenario in message 31 of
#802211. Now, tell me:

Once an attacker has managed to start rescue mode,
what exactly is one extra root password going to accomplish?!

For a simplistic security configuration of GRUB, there is just one
password for both editing commands and activating the recovery mode.
So, if you're able to start recovery mode because you managed to get
that password, then that same password would also allow you to start
"init=/bin/bash" and bypass root logon anyway.

You might then want to distinguish between a recovery user (who may
activate the recovery mode option) and a real superuser (who may issue
arbitrary GRUB commands). Then, the recovery user would indeed still
have to punch in the root password, so an attacker would need to steal
two passwords rather than just one. However, you'll have to already
configure some less than trivial authentication and authorization
in GRUB. Why would you want to duplicate that effort with sulogin
parsing /etc/passwd if you somehow know beforehand that the root account
is enabled? Is there really a plausible scenario where you can steal
the password of the GRUB recovery user, but you can't steal the second
password that user needs before any recovery can be performed? I doubt
that barrier reduces more risk than it costs, especially when there
is a sane password policy in effect.

I urge the maintainers of the systemd package to outright dismiss this
kind of scenarios. Those hand-wavy excuses only arise because paranoia
makes one want to defend existing practices. Security is about
mitigating risks, which instead requires clear and well-founded
arguments. And sometimes that means you'll conclude you have to do
things in a way you're not used to, such as entirely disabling root
accounts.

If you truly care about security, you know very well that any process
running as root is a liability (even when you're running a kiosk),
and you also know very well that disabling "login as root" for
**normal, everyday operation** is part of any healthy security policy
and an important mitigation w.r.t. automated attacks.

Rescue mode is reserved for special occasions, so it deserves
a tailor-made solution -- as long as that solution doesn't affect
normal, everyday operation. Moving the responsibility of securing rescue
mode to the bootloader, which needs to be secured *anyway*, seems like
a suitable solution.

Enabling the root account by setting a password, or even setting a flag
that indicates that the account is only for rescue mode (as suggested
by Kevin Locke), is not a suitable solution. It would place the root
account back in the realm of "normal, everyday operation", where people
who (let alone: software that) didn't get the memo about that special
flag will probably not enforce the intended policy, and where plenty of
software will happily make authentication attempts for root when asked
by an otherwise unauthenticated user (see for instance CUPS' web
interface).

If someone is stubborn enough to wave away modern best practices,
let them do so, but let them also deal with the fallout. A big screaming
warning that their pathological case is insecure should suffice. But for
sake of the rest of us, who just want to use Debian in a sane and
safe way, please prioritise rootless installations, throw in
the `--force` flag and fix this 720-days-and-counting-old bug (you can
always add that "but don't --force when root is enabled" logic later).
Alternatively, have the guts to admit that you think that rootless
installations are a misfeature and tell the debian-installer to remove
that option. It's one or the other, because as it stands now,
those installations don't have a functioning rescue mode.

Last but not least, the maintainers must be aware that this bug in fact
constitutes a security problem. I'll gladly admit that I am to blame
for harming the availability of my system, but every second I spent on
working around this bug is on systemd.

Regards,
Stijn van Drongelen

 [1]
https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20171011/609e4f5d/attachment.html>