<div dir="ltr">Hi everyone,<br><br>Today, I was fiddling around a bit with nVidia drivers. I was fed up<br>with the constant screen tearing, and decided to try fixing it once more.<br>In the end, I hit a fatal bug in nvidia_drm that triggers when X starts.<br><br>This taught me two things:<br><br>1) I really should back up more often.<br>2) I really should understand solutions before applying them.<br><br>I could recover my system, if only I could prevent X from loading before<br>I can revert the settings by moving and deleting some files. I rebooted<br>and tried starting the rescue mode.<br><br>This taught me two things:<br><br>3) The behaviour described in this bugreport exists.<br>4) The people responsible for resolving this bug are avoiding any kind<br>   of honest security analysis.<br><br>Let's assume for a second that the Debian installer offers the option<br>to password-protect GRUB. When configured properly, this prevents an<br>unauthenticated user from opening the console, editing options, and<br>from starting specific boot variants (such as rescue mode; see [1]).<br>The fact that the Debian installer doesn't offer this option is IMO<br>not merely something that warrants a feature request, but a huge glaring<br>security problem.<br><br>Let's also assume that, whoever installed the system, had the knowledge<br>and forethought to lock down any options in the BIOS that would allow<br>anyone from booting anything else than that password-protected GRUB.<br><br>That should match Michael Biebl's example scenario in message 31 of<br>#802211. Now, tell me:<br><br>Once an attacker has managed to start rescue mode,<br>what exactly is one extra root password going to accomplish?!<br><br>For a simplistic security configuration of GRUB, there is just one<br>password for both editing commands and activating the recovery mode.<br>So, if you're able to start recovery mode because you managed to get<br>that password, then that same password would also allow you to start<br>"init=/bin/bash" and bypass root logon anyway.<br><br>You might then want to distinguish between a recovery user (who may<br>activate the recovery mode option) and a real superuser (who may issue<br>arbitrary GRUB commands). Then, the recovery user would indeed still<br>have to punch in the root password, so an attacker would need to steal<br>two passwords rather than just one. However, you'll have to already<br>configure some less than trivial authentication and authorization<br>in GRUB. Why would you want to duplicate that effort with sulogin<br>parsing /etc/passwd if you somehow know beforehand that the root account<br>is enabled? Is there really a plausible scenario where you can steal<br>the password of the GRUB recovery user, but you can't steal the second<br>password that user needs before any recovery can be performed? I doubt<br>that barrier reduces more risk than it costs, especially when there<br>is a sane password policy in effect.<br><br>I urge the maintainers of the systemd package to outright dismiss this<br>kind of scenarios. Those hand-wavy excuses only arise because paranoia<br>makes one want to defend existing practices. Security is about<br>mitigating risks, which instead requires clear and well-founded<br>arguments. And sometimes that means you'll conclude you have to do<br>things in a way you're not used to, such as entirely disabling root<br>accounts.<br><br>If you truly care about security, you know very well that any process<br>running as root is a liability (even when you're running a kiosk),<br>and you also know very well that disabling "login as root" for<br>**normal, everyday operation** is part of any healthy security policy<br>and an important mitigation w.r.t. automated attacks.<br><br>Rescue mode is reserved for special occasions, so it deserves<br>a tailor-made solution -- as long as that solution doesn't affect<br>normal, everyday operation. Moving the responsibility of securing rescue<br>mode to the bootloader, which needs to be secured *anyway*, seems like<br>a suitable solution.<br><br>Enabling the root account by setting a password, or even setting a flag<br>that indicates that the account is only for rescue mode (as suggested<br>by Kevin Locke), is not a suitable solution. It would place the root<br>account back in the realm of "normal, everyday operation", where people<br>who (let alone: software that) didn't get the memo about that special<br>flag will probably not enforce the intended policy, and where plenty of<br>software will happily make authentication attempts for root when asked<br>by an otherwise unauthenticated user (see for instance CUPS' web<br>interface).<br><br>If someone is stubborn enough to wave away modern best practices,<br>let them do so, but let them also deal with the fallout. A big screaming<br>warning that their pathological case is insecure should suffice. But for<br>sake of the rest of us, who just want to use Debian in a sane and<br>safe way, please prioritise rootless installations, throw in<br>the `--force` flag and fix this 720-days-and-counting-old bug (you can<br>always add that "but don't --force when root is enabled" logic later).<br>Alternatively, have the guts to admit that you think that rootless<br>installations are a misfeature and tell the debian-installer to remove<br>that option. It's one or the other, because as it stands now,<br>those installations don't have a functioning rescue mode.<br><br>Last but not least, the maintainers must be aware that this bug in fact<br>constitutes a security problem. I'll gladly admit that I am to blame<br>for harming the availability of my system, but every second I spent on<br>working around this bug is on systemd.<br><br>Regards,<br>Stijn van Drongelen<br><br> [1] <a href="https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation">https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation</a></div>