Locked root and rescue mode [LWN.net]

By Jake Edge
December 22, 2021

Fedora is among the group of Linux distributions that, by default, lock out the root account such that it does not have a password and cannot be logged into. But, traditionally, "rescue mode" boots the system into single-user mode, which requires a root password—difficult to provide if it does not exist. A Fedora proposal to remove the need for the password in that case, and just drop into a root shell, does not seem likely to go far in that form, but it would seem to have pointed toward some better solutions for the underlying problem.

The proposal for Fedora 36, "Make Rescue Mode Work With Locked Root", was posted on December 6 by Fedora program manager Ben Cotton on behalf of the feature owners: Michel Alexandre Salim, Neal Gompa, and David Duncan. The problem is that the "out-of-the-box user experience" is poor for systems with a locked root if users have a need to fix their systems via single-user mode; they will be prompted for a password that they cannot provide and have to resort to other means of booting their ailing system (e.g. rescue boot media). Another option is to boot with a kernel command-line option such as "init=/sysroot/bin/bash", but that is not particularly user-friendly either.

The guts of the change would use the --force option to sulogin to skip the password requirement when entering single-user mode if the root password is not accessible or the root login is disabled. But, as that man page warns, the option should only be used "if you are sure the console is physically protected against unauthorized access". The proposal says that the change "does not pose an increased security risk", because attackers already have other means of bypassing the password (e.g. init=) or compromising the system if they have physical access. Those who want to enforce a password for single-user mode can simply set the root password.

The implementation would be based on a similar feature (patch) in Fedora CoreOS. By default, Fedora 36 would install an RPM that changes the systemd configuration to bypass the password. Users or Fedora variants that do not want that behavior can remove or not install that RPM.

As might be guessed, the claim that there is no increased risk drew comments. Zbigniew Jędrzejewski-Szmek said that there are at least two cases where having physical access does not necessarily lead to the ability to compromise the system:

If the data is encrypted, then being able to override the init doesn't achieve anything, until the decryption has been performed. 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.

The problem being addressed does exist, he said, but the solution is not a good one:

Essentially, you are proposing a behaviour of "something is wrong, let's make everything open without authentication", which is good for debugging and development, but not acceptable for a real system.
The correct solution is to enhance login mechanisms so that it is possible to authenticate using existing credentials also in the rescue mode. The fact that this is not possible right now is a bug that needs to be fixed.

He had some suggestions for ways forward, including potentially adding a password hash (using the stronger yescrypt hashing algorithm) to the initial ramdisk (initrd) or elsewhere that is accessible at boot time (e.g. EFI variables). In addition, the Trusted Platform Module (TPM) could be used to encrypt the password in a system-specific fashion.

Richard W.M. Jones wondered about the threat model and how skipping the password would actually cause problems; "On the flip side I have hit the problem described and it's incredibly annoying - it makes rescue mode useless in the default case." Jędrzejewski-Szmek acknowledged that the problem is "annoying and real", but noted that the proposal violates some fundamental properties that govern system access:

There are many many different ways in which systems are installed, but the general principle is that [once] the system is up, you need valid credentials to log in. So protecting the system before it's running, i.e. protecting the data at rest, can be done in many different ways and is your responsibility, after it is up, you know that the normal system mechanisms apply. With the proposal this promise is broken.

One example he gave was for a kiosk-installed system, where users have access to the keyboard; "if you can affect the system so that it does not boot properly, even by causing a sufficient delay, [it] is enough to get unrestricted access."

Vit Ondruch asked about any existing work toward the solution proposed. Jędrzejewski-Szmek said that recent versions of systemd have support for the low-level plumbing (i.e. encrypted-secret storing), but the higher-level pieces are still missing:

But we're missing the upper parts, i.e. how to actually use and update the passwords. I didn't even mention this, because we don't have a comprehensive story yet. I think it'd be necessary to write some pam module and/or authentication helper from scratch.

The "wheel" group on Fedora (and other Unix systems) is meant to contain administrative users, so it would make sense to accept any password for users in that group as equivalent to that of root, Lennart Poettering said. He agreed that there is still work to do to collect up those passwords, encrypt them with the TPM, and store them where they are accessible at boot time, but the net effect would be useful well beyond just booting into single-user mode:

With such a mechanism we would have quite nice semantics: if a user is designated to have admin privs, then that's sufficient to be able to log into the root account, no further manual work necessary, and it applies to the whole runtime of the OS: from initrd to regular system, to sudo.

Chris Murphy was concerned about tying the solution to the existence of a TPM, since there are systems that do not have the device or it is not supported by the kernel. Poettering said that using the TPM by default makes sense even if there is a need to "find graceful fallbacks for environments that are more limited".

But Chris Adams was in favor of the original proposal; administrators who want to further lock down their systems can simply do so by removing the RPM or setting a root password. "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." Jędrzejewski-Szmek said that was a step backward:

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.

Murphy also wondered about the Fedora CoreOS change. If the idea of skipping password checking is terrible: "Is it terrible enough that CoreOS should revert?" Jędrzejewski-Szmek said that it makes the CoreOS image unsuitable for general-purpose use; "Maybe it's OK in limited circumstances where 'physical' access is only possible if you're the administrator on the host."

While the feature owners did not participate much in the discussion, Salim was obviously keeping track of the feedback. He said that he was inclined to not rush a full solution for Fedora 36 and to push that back until Fedora 37. He noted that the question of what CoreOS should do is a good one. Beyond that, the questions of using the wheel group to delimit which passwords are valid and whether or not to add TPM dependencies for the feature need to be resolved.

He also wondered about some kind of recovery password, which had been raised in the thread as means to work with disks that need to be installed in another system (with a different TPM). That problem was seen to be a separate issue. In addition, Björn Persson thought that a recovery password was more appropriate for scenarios where a different authentication mechanism (e.g. hardware token) is used—and could get lost or broken:

As long as users normally log in with a passphrase, I see no need to have a separate passphrase for rescue mode. Root's or a wheel user's usual passphrase should be fine.

To address the immediate needs for Fedora 36, Salim suggested just removing rescue mode as a boot option if no root password is set. In addition, if someone tries to invoked rescue mode from the command line in that scenario, "it should display an error rather than prompting for a non-existent password". Persson thought that all sounded reasonable. The Fedora Engineering Steering Committee was slated to discuss the proposal at its December 20 meeting, but that was canceled due to a lack of quorum; it will presumably be rescheduled for the next meeting on January 3.

Overall, the idea of using wheel group passwords seemed to gain a fair amount of traction, as did not opening up new ways to get root without any authentication. Our systems are complex enough, and installed in so many different ways and environments, that doing so was always going to raise some eyebrows. On the other hand, though, prompting for a password that cannot be provided is a sure path to user frustration—at a time when said user is probably already worried about the functioning of their system and does not need further headaches. The path to a better solution for that problem seems fairly clear; with luck we will see it in Fedora 37, coming in late 2022.

Index entries for this article
Security	Distribution security

to post comments

Locked root and rescue mode

Posted Dec 22, 2021 6:44 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (10 responses)

Does Fedora not have an interactive installer? Because to my mind, there are really only two cases here:

1. You want anyone with physical access to the machine to have de facto root.
2. You don't.

There are legitimate reasons for both of these positions, but they are clearly irreconcilable. Either you do or you don't want to allow it. Sure, there might be some middle ground that is vaguely acceptable to both groups, but just offering an "enable/disable rescue mode" option would probably give both sides exactly what they want. I suspect that the vast majority of people who are genuinely in case (2) are just going to reimage it rather than trying to fix it, for example.

Locked root and rescue mode

Posted Dec 22, 2021 8:22 UTC (Wed) by madhatter (subscriber, #4665) [Link] (3 responses)

I agree, but worse, people taking position two are already in trouble. Giving someone physical access to a Linux system while relying on the machine itself to vet ongoing access is doomed to failure. Not only could one provide circumventing arguments to init or boot from rescue media, one could remove the persistent storage device and carry it to a hostile system. There are many further attacks which fall into the evil-maid category. The long and short of it is that if anyone has, or has had, unrestricted physical access to your machine, it's not reliably your machine any more. (The exception to this is encrypted data which the machine cannot decrypt, where an external source such as a legitimate user must provide a passphrase unknown to the machine, usually at boot time, but that's not what's being discussed.)

It annoys the heck out of me when distributions try to add one last, highly-circumventable-yet-highly-annoying step to single-user boot, because every distro needs slightly different circumventing measures, while I need to get their system wide-open as fast as possible so I can fix it.

Locked root and rescue mode

Posted Dec 22, 2021 8:38 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

Oh, it's entirely possible to construct a system that automatically decrypts itself if the boot chain is intact, but refuses to do so if anyone has tampered with it in any way. It's also then possible to have the system attest to some other device that an attacker didn't have physical access to, in order to demonstrate that it's in its original state rather than just pretending to be. The key differentiating factor in a design that respects the freedoms of the owner is that it should absolutely be possible to disable as much of this functionality as you want - but doing so should (a) be something the owner can detect, and (b) should not grant access to any sensitive material as a result.

The combination of UEFI secure boot and Bitlocker in Windows gets most of the way here, other than providing a reliable mechanism for determining whether a machine has been tampered with before entering credentials. Linux is behind the curve.

Locked root and rescue mode

Posted Dec 22, 2021 9:09 UTC (Wed) by madhatter (subscriber, #4665) [Link] (1 responses)

Sorry, Matthew, you're absolutely right (of course), and I should've remembered you actively read here. Given a reliable TPM, a stable software platform resting on it, and the ability of appropriate parties to produce TPM-satisfactory signatures of various elements of those platforms, one can indeed have the security you suggest. I've never actually worked on a system like that, and I never expect to, but I agree that it's a completely feasible thing.

Locked root and rescue mode

Posted Dec 22, 2021 9:31 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

To be fair, I don't want to overstate this - while Windows is ahead of what Linux provides here, it's still not perfect, and someone's going to need to throw a fair amount of effort at the problem to turn it from something that's possible to something that actually exists.

Locked root and rescue mode

Posted Dec 22, 2021 15:39 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (4 responses)

> just offering an "enable/disable rescue mode" option would probably give both sides exactly what they want.

No way. How can you expect users to know what rescue mode is, let alone have enough expertise to evaluate the question of whether they want it enabled or not? Why would we add an option to the installer when everyone agrees it is possible to develop a technical solution to fix rescue mode and avoid the problem altogether?

The installer is not the right place for anything except the most important options. We devs like to joke about "if I had a dime for every time somebody suggested adding an option to the installer" because this comes up rather a lot, often for silly things that can be easily changed post-installation (e.g. vi vs. nano). *Occasionally* it does make sense to add something to the installer, but this is very rare.

Locked root and rescue mode

Posted Dec 22, 2021 22:00 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

My position is that the people who truly need (2) know exactly who they are and exactly what they want the distro to do. This is because it is impossible to actually have (2) without hardware support (e.g. a TPM), and in most cases a decent amount of supporting infrastructure (e.g. your own private PKI system). If you don't have those things, then you don't actually have (2) anyway, and the distro should not provide the illusion of (2) by locking out rescue mode. Furthermore, the people who are really administering systems in that sort of environment are, as I said, not actually logging into rescue mode and fixing them one at a time in the first place (at least in most cases).

(Yes, full-disk encryption exists, but it solves a different problem altogether - "I don't want the system to boot, nor any data to leave the system, unless the user has authenticated with a passphrase." Whether to give the user root after they have already unlocked the disk is a separate issue of authorization.)

Locked root and rescue mode

Posted Dec 23, 2021 8:48 UTC (Thu) by comex (subscriber, #71521) [Link] (2 responses)

A TPM is hardly an exotic dependency these days (at least if you count firmware TPMs); Windows 11 requires one to even run the OS.

Supporting infrastructure is another matter.

Locked root and rescue mode

Posted Dec 23, 2021 15:29 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

Sadly firmware TPMs are almost always disabled by default, and modifying complicated UEFI firmware settings is a *big* hurdle to clear, so fallback behavior for the non-TPM case is going to be important for a long time.

Again, though, it hardly matters for this issue because everyone agrees we don't need a TPM to fix rescue mode.

Locked root and rescue mode

Posted Dec 24, 2021 3:03 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

A TPM is necessary but insufficient. A malicious user can replace any or all of the hardware, run the whole OS under a hypervisor, etc., and a TPM is not realistically adequate to defeat such measures. You would at least need to pair it with something like UEFI secure boot to prevent such attacks, but that can be non-trivial to enable for an arbitrary system, especially if the hardware/firmware was not specifically designed to run Linux, or if it requires nonstandard drivers or other kernelspace chicanery. Even then, people have been rooting smartphones for a very long time, and I remain skeptical that you can actually provide online security (i.e. "it's still secure even if the computer is running and doing useful work") against a user with physical access.

Locked root and rescue mode

Posted Dec 23, 2021 8:51 UTC (Thu) by smurf (subscriber, #17840) [Link]

1. You (most likely) want to flatten your hard disks, thus pre-existing data and encryption are irrelevant.

2. You don't.

Locked root and rescue mode

Posted Dec 22, 2021 9:07 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

What is the purpose of locking the root account in the first place?

I can see how it might be useful if you have multiple people doing admin work to distinguish them (but that is really only useful if audit logging is turned on) but for your average home desktop system I just don't see the point.

Is this a requirement that was mainly introduced to that home use-case by installer UI designers who wanted one less step in the installer (asking for a root password)? Can home users not be trusted to not work as root if you don't lock it down?

Locked root and rescue mode

Posted Dec 22, 2021 10:53 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

What's the purpose of the root account in the first place!? It's extremely dangerous!

imho the Pr1mos technique made much more sense - the only super-power the super-user had was the ability to edit access rights.

But the system console did boot straight into super-user status (though I believe that could be disabled).

Cheers,
Wol

Locked root and rescue mode

Posted Dec 22, 2021 12:00 UTC (Wed) by smoogen (subscriber, #97) [Link]

I only worked on a Pr1me 200 and Pr1me 300 and for those early versions of Pr1mOS it always booted into super user mode but only serial console 0 was enabled. That one also accepted special key commands so was meant to be locked in a secure room just like the Pr1me was because if you had physical access to the mini you could put the system into single user and toggle front panel toggles for any process. [Which was the real 'root' of the system. live patch any process.. just slowly toggle through next, next, next.. change that machine code, next, change the machine code, next, run. Saw a flown in consultant do it once to get my system booted.]

Locked root and rescue mode

Posted Dec 22, 2021 10:11 UTC (Wed) by pwfxq (subscriber, #84695) [Link] (4 responses)

We're not going to allow root login because you can do bad things. Instead, we're going to create a different login to allow you to do bad things.

Locked root and rescue mode

Posted Dec 23, 2021 10:31 UTC (Thu) by Spack (subscriber, #77556) [Link] (3 responses)

The difference is that from the outside, potentially, you don't know the name of such users and you don't know which ones can break the system.

Locked root and rescue mode

Posted Jan 7, 2022 16:10 UTC (Fri) by bored (subscriber, #125572) [Link] (2 responses)

This seems suspect because the argument is summarized as: The user/root passwords are insecure so we are hoping to gain some additional entropy via the username.

Locked root and rescue mode

Posted Jan 7, 2022 16:39 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

And as long as you don't RELY on that, it makes good sense.

Security by obscurity does not make sense as your MAIN defence. As a backup, to make an attacker's life harder, it makes a LOT of sense. Witness the RSA hack, where (I read a post-mortem) they think an attacker asked a bunch of seemingly innocuous questions at a conference precisely so they could work out how to get through the defences without triggering any alarms.

Security by obscurity clearly failed here, which is why you shouldn't rely on it, but against your casual hacker (not somebody specifically targeting you) it would almost certainly have caught them, and quickly.

Cheers,
Wol

Locked root and rescue mode

Posted Mar 12, 2022 12:53 UTC (Sat) by immibis (subscriber, #105511) [Link]

When security by obscurity causes problems for regular users more than it does for attackers, you stop doing it.

Locked root and rescue mode

Posted Dec 22, 2021 10:36 UTC (Wed) by kim (guest, #73716) [Link] (4 responses)

It seems that on Ubuntu (and maybe derivatives, and maybe also on Debian), the first account created while installing is sudoer (by default) and in case the root password is absent, the rescue boot asks for that user's password. If a root password is set, the user is prompted for the root password.

I think it's a good compromise for the single user case. For multi user, as noted, the admin needs to take other steps to prevent admin login anyway (such as securing the boot loader).

But maybe it requires some trickery to maintain this user's credentials on the initramfs now that I think about it.

Locked root and rescue mode

Posted Dec 22, 2021 15:43 UTC (Wed) by smcv (subscriber, #53363) [Link] (1 responses)

> It seems that on Ubuntu (and maybe derivatives, and maybe also on Debian), the first account created while installing is sudoer (by default) and in case the root password is absent, the rescue boot asks for that user's password.

In debian-installer, if you set a root password, then the first user account is not root-equivalent. If you don't set a root password, then we have the Ubuntu behaviour where the first user account is root-equivalent: this is implemented by adding it to the sudo group, which is an "admin" account (allowed to do privileged things) via polkit, and also directly root-equivalent via sudo or pkexec.

Locked root and rescue mode

Posted Dec 22, 2021 16:10 UTC (Wed) by mattdm (subscriber, #18) [Link]

This is exactly the same in Fedora Linux (although the group used is "wheel" rather than a "sudo" group, for whatever historical reason — presumably someone at Red Hat long ago with a BSD background).

Locked root and rescue mode

Posted Dec 23, 2021 9:55 UTC (Thu) by mgedmin (guest, #34497) [Link] (1 responses)

I believe that Ubuntu simply gives you a passwordless root shell if you select rescue mode from the GRUB boot menu. (To be more precise, there's an interactive text-mode menu that presents the root shell as one of the options.) AFAIU if you do set a root password (which is not the default configuration), then rescue mode will also ask for it.

The argument is the same one that was presented here: if you have access to the boot loader, you can always boot with init=/bin/sh and manually mount root etc. from the initramfs shell, or boot a live system and chroot. If you want security, use a boot password or full disk encryption.

Locked root and rescue mode

Posted Dec 28, 2021 7:43 UTC (Tue) by ah (subscriber, #85449) [Link]

Yes ubuntu gives passwordless root. See sulogin-lockedpwd.patch in ubuntus util-linux package ... (here's the current diff between debian and ubuntu: https://patches.ubuntu.com/u/util-linux/util-linux_2.37.2... )

Locked root and rescue mode

Posted Dec 22, 2021 10:52 UTC (Wed) by evgeny (subscriber, #774) [Link]

The first thing I do after having installed such a distribution is "sudo -i && passwd".

I understand the arguments about security issues with no-root-pass in the recovery mode if a disk is encrypted. But first, how many such installations exist (in %% of the total)? Second, I think no general-purpose distribution enables disk encryption by default. So why not make the two options mutually dependent? If disk encryption is checked, the root is locked, and vise versa.

Locked root and rescue mode

Posted Dec 22, 2021 12:12 UTC (Wed) by smoogen (subscriber, #97) [Link]

The following commentary comes under 'Fear, Uncertainty, and Dread/Doubt'. I know this and accept that it might not be helpful for the debate, but after reviewing the change request, it is all I am filled with.

My main issue with this mode of 'fixing the problem' is that it would fail the spirit of most .gov/.mil/.com security mandates/requirements for purchase and thus make the system unusable in said environments. Many of them are using the 'secure when shipped and made insecure only by admin decisions' paradigm for what is allowed onto their networks. Things which violate that are items which I know a lot of sites will just say 'unusable by design, only allowed by executive exception.' Mainly because we know at some point, someone will forget to set the root password or remove the package or something and there will be a world of hurt.

A former CSO I worked under put it "There are days when you are in the Wall Street Journal, and there are days when you are on the front page. Our job is to make it so security problems aren't the reason that happens." This is one of those changes I would read and assume I will be on the front page because of it.

Locked root and rescue mode

Posted Dec 22, 2021 13:20 UTC (Wed) by syrjala (subscriber, #47399) [Link] (7 responses)

I never really understood why disabling root password is so desirable. Why is using sudo somehow superior? To me sudo seems less secure since if you manage to figure out the user's password and login remotely then you can just sudo your way into doing anything. If you don't use sudo then you'd still need to find out the root password (or a privilege escalation) to get root access. And let's not forget the recent sudo vulnerability...

Locked root and rescue mode

Posted Dec 22, 2021 13:31 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

To log in, you need two things, a username and a password.

In the case of 'root' you already know the username, so you only have to guess/crack/social engineer a password.

In the case of 'root' that account can already do _everything_ whereas the user account may or may not have sudo rights.

So for 'bang for the buck' you attack the 'root' user first. Modern sensibilities that disable remote root login greatly mitigate this, but it IIRC has to be implemented on a per-service basis whereas disabling the 'root' account altogether takes care of it all with minimal effort.

Locked root and rescue mode

Posted Dec 22, 2021 15:04 UTC (Wed) by syrjala (subscriber, #47399) [Link]

I guess that's true when you have local access. For remote logins sudo seems to expose a larger attack surface, unless you're crazy enough to allow remote root login.

Locked root and rescue mode

Posted Dec 22, 2021 19:40 UTC (Wed) by Wol (subscriber, #4433) [Link]

Can't you just change the name of user 0?

Cheers,
Wol

Locked root and rescue mode

Posted Dec 22, 2021 20:30 UTC (Wed) by floppus (guest, #137245) [Link]

On systems where admin duties are shared, I'd prefer not to have to have a single root password that must be communicated to all administrators.

I'd also prefer to have logs showing who was the actual person who logged in and broke the thing.

Locked root and rescue mode

Posted Dec 22, 2021 22:54 UTC (Wed) by lobachevsky (subscriber, #121871) [Link]

It's mainly about logging. sudo can log who is sudoing what, it can even record whole sessions for audit purposes.

Locked root and rescue mode

Posted Dec 23, 2021 15:09 UTC (Thu) by james (guest, #1325) [Link]

What worries me is using things like

sudo rm $WHATEVER

from my normal account, especially since I use shell history a lot: it's too easy to bring up the wrong command. Or, come to that, if you regularly spell rm as sudo rm, or teach less-skilled colleagues that sudo is the Big Hammer That Makes It Work, a normal account is pretty close to root anyway. At least with sudo su - (or something like that) you have a chance to realise "that command spells Be Careful"!

I do want to have privileged commands in some sort of shell history, so I can write a command with echo in the right place to confirm what it does, then edit the command line to remove the echo once I'm happy.

I probably ought to insist on separate unprivileged accounts and per-user admin accounts, with only the latter having passwordless sudo access to all commands. I don't remember ever seeing that being recommended, though.

(And no, I do not like "enter a password every 15 minutes" as a UI: I will decide when I go into and out of privileged mode, thank you very much...)

Locked root and rescue mode

Posted Dec 23, 2021 18:05 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

I think the big advantage of sudo over root is that it is administratively easier. Because enhanced access with sudo comes by using the user's existing password, you can revoke their access by disabling their account or removing them from sudoers. In contrast, with a single root password, you need to change the password every time someone's access is revoked. That may not be a big deal on a single user desktop system, but it gets to be a real burden in a large organization with dozens or hundreds of people who need administrative access.

Similarly, sudo is much neater if you want finer-grained control over who has administrative rights on which machines. You just need per-machine sudoer files. If you want to do the same thing with a traditional root setup, you need a separate password for each unique set of administrators. Again, it's not a big problem for small organizations where there might be only one administrator, but it gets to be impractical in a large organization with lots of different administrator groups.

Confusing unrelated issues

Posted Dec 22, 2021 18:53 UTC (Wed) by floppus (guest, #137245) [Link]

Although the idea of using a TPM to store or verify passwords is an interesting one (good or bad is debatable), that's completely orthogonal to the question of whose username/password should be usable to log in in rescue mode.

The status quo is that "sulogin" can be used to log in using root's password, assuming that root has a hashed password in /etc/shadow. Extending the same level of trust to "anyone who has a hashed password in /etc/shadow and is listed as a member of wheel in /etc/group" doesn't change the fundamental security properties of the system.

(At least on Debian, "sulogin" is only available after the root filesystem has been mounted - it's not in the initramfs. I don't know if the same is true on Fedora; there are arguably some advantages and also a lot of disadvantages to providing a "sulogin" within the initramfs, but those issues are again quite orthogonal to the question of *whose* username/password is allowed.)

Locked root and rescue mode

Posted Dec 22, 2021 20:05 UTC (Wed) by Subsentient (guest, #142918) [Link]

Or maybe just don't lock the root account in the first place? I don't personally think that the minor security benefits are worth the inconvenience and complexity. As to those questioning the existence of a root account at all, a root account with unlimited capabilities is part of what makes Linux desirable to me, I don't want to see it neutered like macOS has done.

Root is an escape hatch I can use to force the system to do what I want, even if the OS disagrees with the wisdom of doing so. A free operating system should have no need or desire to remove that escape hatch.

Single user mode unlocked before

Posted Dec 22, 2021 20:42 UTC (Wed) by jccleaver (guest, #127418) [Link] (8 responses)

EL6 era machines, when booted into single user mode, drop you straight into the shell. I really fail to see why booting to require a root password is more secure here, other than that the systemd kabal decided to make admin's lives more difficult, as usual.

If you don't want people to init=/bin/bash, then you need to password protect GRUB in the first place. If they can do that, they can boot in single and end up in almost the exact same spot.

Single user mode unlocked before

Posted Dec 23, 2021 6:43 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

The blaming of “systemd cabal” for something systemd developers aren’t involved in and in fact questioning the value of this change as evidenced by their posts on the linked thread is misguided.

Single user mode unlocked before

Posted Dec 23, 2021 21:02 UTC (Thu) by salimma (subscriber, #34460) [Link]

I think jccleaver is actually /in favor/ of the change. And as one of the change owners, I appreciate the feedback from systemd developers on alternate ways to do this in a more secure manner, TBH.

I should note that systemd doesn't require this to be locked down, the `--force` mechanism would fully work on systemd based systems and their support for drop-in config overrides makes this much easier to manage than, say, trying to override DNF repo configs.

Single user mode unlocked before

Posted Jan 1, 2022 18:42 UTC (Sat) by gorpon (subscriber, #25040) [Link] (5 responses)

On the contrary. If they don't want to be implicated in so many problems, perhaps they should have considered *not* implementing a mind numbing array of different features that puts systemd in the middle of virtually every problem that might arise with a computer.

Single user mode unlocked before

Posted Jan 1, 2022 19:54 UTC (Sat) by Wol (subscriber, #4433) [Link]

Well at least they didn't implement a mind numbing array of WAYS of implementing those features ... :-)

Cheers,
Wol

Single user mode unlocked before

Posted Jan 1, 2022 22:13 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Why? Having reliable infrastructure for a mind-numbing range of issues is awesome.

Single user mode unlocked before

Posted Jan 2, 2022 4:11 UTC (Sun) by gorpon (subscriber, #25040) [Link] (2 responses)

It certainly sounds awesome, doesn't it? But consider how the tightly coupled designs can be inconvenient.

If I want to change or replace the code for one feature, I cannot simply only swap out the software for that component. Rather, for most distros, I must recompile and repackage all of systemd to ensure that dependencies are met correctly and reinstall. Were the features implemented by separate, more focused projects, there would be little risk of cross-impact. I.E., changing my network initialization doesn't have to change the programs on-disk for my storage initialization.

Is that significant? Suppose I want to take advantage of a newer version, but only for a specific component, but I cannot risk modifying other components; perhaps there is some other newer behavior of another component that we're not ready to adopt? I don't see a way to do that, without the OS vendor saying something to the effect of "I wish you good fortune and fair weather, my friend. You are on our own." But even to establish that is the case, we must fully test how it affects the entire system, rather than just that component.

Single user mode unlocked before

Posted Jan 2, 2022 11:03 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> If I want to change or replace the code for one feature, I cannot simply only swap out the software for that component.

You still can do that. Just disable systemd's network handling and go wild with custom scripts.

It looks awkward and ugly because suddenly you drop down to the Bad Old Unix Days and have to do everything manually.

> Were the features implemented by separate, more focused projects, there would be little risk of cross-impact. I.E., changing my network initialization doesn't have to change the programs on-disk for my storage initialization.

systemd is just a bunch of executable files. Nobody stops you from replacing one of them. Having all these modules in one umbrella project allows to integrate and test them together.

Single user mode unlocked before

Posted Jan 4, 2022 11:24 UTC (Tue) by farnz (subscriber, #17727) [Link]

But systemd isn't a tightly coupled design; it's a set of executables that share common code with each other. You can (I have, in the past) swap out systemd-networkd without affecting the init system, and you can do the same for any other systemd component. There's even Meson options provided by upstream to make it easier to build separate executables for each component of systemd that don't overlap, so that you can do what I did (set the "standalone-binaries" Meson option when building, and copy the -standalone binary instead of the shared one).

Beyond that, all the other issues you describe are exactly the same as I faced before systemd; the moment I change a system component, the OS vendor says it's my problem, even if I only change one component. Doesn't matter how coupled they are - I've changed something they don't control, and they will refuse to support me.

Locked root and rescue mode

Posted Dec 24, 2021 0:20 UTC (Fri) by gdt (subscriber, #6284) [Link]

Not too keen on the proposal to allow any wheel-holder password. Say wheel user abc is a threat, so that account is locked on the authentication service. But abc can trivially regain access using the credentials to the locked account.