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
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
