use non root account for rescue.service and emergency.service
imthenachoman opened this issue · 10 comments
Is your feature request related to a problem? Please describe.
Both rescue.service and emergency.service will try to drop to a root shell. If the root account is locked then you'll get an error message Cannot open access to console, the root account is locked. The only way to fix this is boot the OS using a recovery drive and/or use the --force option in /lib/systemd/system/rescue.service for /sbin/sulogin in the ExecStart option.
ExecStart=-/bin/sh -c "/sbin/sulogin -- force; /bin/systemctl --job-mode=fail --no-block default"
Neither are good solutions or very secure.
Describe the solution you'd like
Instead, if rescue.service and emergency.service dropped to a non-root user shell for a user that has sudo as root privileges, then the user can still repair/rescue the system and it is secure.
The idea is that, if you select to lock the root account, then you'd provide the login ID of a user to use in some config file. At boot, systemd would look at that file for the ID to use and then open a shell as that ID. The user would have to enter their password and then they could sudo -s to root.
So, maybe the ExecStart line in /lib/systemd/system/rescue.service for /sbin/sulogin could look something like:
ExecStart=-/bin/sh -c "/bin/su - $(cat /etc/admin.conf) ..."
And /etc/admin.conf would have:
nacho
This would be a more secure option. I am working on a new Debian install and might try this out to see if I can get it to work.
Describe alternatives you've considered
N/A
Additional Information
This idea is a continuation of these threads:
I am not sure there's much benefit in playing these games too much. I think there's a point to be made that maybe SYSTEMD_SULOGIN_FORCE should default to on, but introducing a new user just to play indirection games in one corner cases appears very much unnecessary tto me upstream.
That is very risky. Someone could do something during boot, like unplug an external HD, which would force it to go into rescue and then they'd have full root access.
And I am not sure what you mean by introducing a new user? If someone cares about security enough to lock the root account, then they will definitely have a primary/admin account that has sudo as root privileges. It's just a matter of telling systemd to use that instead.
In fact, from a security perspective, this should be the default IMHO. root login should be disabled by default and a primary/admin account should be created. That would be the right thing to do IMHO.
That is very risky. Someone could do something during boot, like unplug an external HD, which would force it to go into rescue and then they'd have full root access.
This would be a more secure option.
In fact, from a security perspective, this should be the default IMHO.
Something can only be more or less secure given a threat model to work with. In this case, I'm finding it hard to come up with a scenario where someone has physical, unmonitored, unprotected access to the computer, and yet we as a userspace application are expected to protect against that.
Threat/risk level is going to be different for everyone. For example, someone could have their server at home, in a back closet maybe, and are worried that during a big party, some bad-actor could sneak of into the back closet without their knowledge/awareness.
And, since the potential solution is, from what I can tell, trivial, even if the risk threat is low, wouldn't it be prudent to implement it? That way, even if someone has, for whatever reason, bad physical security, they are protected?
I get the win in the grand scheme might not be that big but, if it as easy as a solution as I'm thinking it is -- and maybe I am very wrong -- then I'm not seeing the negative to implementing it. And of-course, it would be entirely optional. If, and only if, the user selects to lock the root account during install, it would prompt them if they want to set the account of the primary/admin user that systemd would use for emergency/rescue. :/
I tried this but it does not seem to work. This is what I have done:
# we don't want to edit the main file
# so make a copy in /etc and edit it there
cp /lib/systemd/system/rescue.service /etc/systemd/system/rescue.service
# then change the ExecStart line to look like this
ExecStart=-/bin/sh -c "/bin/su - homie; /bin/systemctl --job-mode=fail --no-block default"
I am testing this by powering off an external USB drive and and booting. It'll go into rescue mode but it still give that same above error.
So, I am pretty sure we don#t want behaviour like this upstream. regular users genreally live on /home (in contrast to /root which lives on the root dir), and the assumption so far was that /home is a late boot thing, and logging in as unpriv user can only be permitted very late, since an unpriv user should not be able to access a system that is only partially running, i.e. where it might take benefit of races and incomplete set up to exploit things. For example a system where tmpfiles.d hasn't been applied yet, or where mounts aren't established and thus hierarchies revealed that are normally overmounted and so on.
Allowing unpriv users to log in early on is hence not something we should really suggest to people, the system is simply not built for that.
Fair enough. That makes sense.
So there is no way to boot into a regular user's account, without /home so they can use sudo?
I will say, as someone who works in cybersecurity, I think this is something to consider for the roadmap. As the threat landscape grows, so does the demand to lock down privileged access as much as possible and use controlled access. Many organizations want to disable the root account completely. Imagine a hardware tech force rebooting your server and taking advantage of sulogin --force to gain access to super confidential data.
But, then agian, maybe supporting this probably requires a more core solution. Maybe creating a root like account without root access/privileges that will still work during rescue and can use sudo...
Sort of reusing this issue for something a bit related - I think if systemd.unit=emergency.target is specified on the kernel commandline, it should behave as if SYSTEMD_SULOGIN_FORCE was specified or so?
Like, I have a passwordless root account to lower security and nuisance (different threat model, right?)
But fsck triggering is already enough to break my boot. So I think this is a problem coming before the init.
Ok it turns out that it's not a fsck request to brick my system, but simply the mounting service failing for that reason.
In util-linux/util-linux#200 it is suggested the distro should query the user for its use case... but for as much as it makes sense, I have really mixed feelings about this added layer of complexity.
Sorry this is an old thread, but it's the most relevant thread I've found.
The issue as I see it is not the tech, or use cases outlining possible scenarios where this might come up. The problem is compliance with various security policies.
For example:
A security policy requires that the root account either be accessed "only" via sudo, and therefore not having a password assigned to it such that direct login to the root account is not possible. Or, if the root account does have a shared password assigned to it, then that password must be rotated frequently, which causes its own issues. The first of these two options is the cleaner more elegant solution, because it eliminates the need for a shared password, and ties everything to individual user accounts, which are granted root access via group membership and sudo.
At the same time this same security policy requires a password in order to enter single user (rescue) mode. It essentially forces the sysadmin to use a shared group password on the root account, even though restricting access to root via sudo is preferred.
I have not seen this mentioned anywhere, but a dedicated password file for rescue/single user mode would separate these concerns. Something like:
----------. root root system_u:object_r:shadow_t:s0 /etc/rescue_shadow
This would separate the concerns of day-to-day operation vs. rescuing a box.
I realize there's a rabbit trail of follow-up questions, such as doesn't that just mean there's another shared password to maintain. Yes that is true, but it separates the risks of day-to-day operation vs. rescuing a box. This is similar to how there is a separate group password for unlocking drive encryption on boot, and another separate group password for unlocking GRUB in order to change boot options.
Doing this would enable the root account to remained locked, accessible only via sudo, while also requiring single user login with a password. The password would be root's password, but useless for anything other than rescuing a box. Thanks.