-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use non root account for rescue.service and emergency.service #11596
Comments
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 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 |
I tried this but it does not seem to work. This is what I have done:
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 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 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 |
Sort of reusing this issue for something a bit related - I think if |
When the root account is locked sulogin will either inform you of this and not allow you in or if --force is used it will hand you passwordless root (if using a recent enough version of util-linux). Not being allowed a shell is ofcourse inconvenient, but at the same time handing out passwordless root unconditionally is probably not a good idea everywhere. This patch thus allows to control which behaviour you want by setting the SYSTEMD_SULOGIN_FORCE environment variable to true or false to control the behaviour, eg. via adding this to 'systemctl edit rescue.service' (or emergency.service): [Service] Environment=SYSTEMD_SULOGIN_FORCE=1 Distributions who used locked root accounts and want the passwordless behaviour could thus simply drop in the override file in /etc/systemd/system/rescue.service.d/override.conf Fixes: #7115 Addresses: https://bugs.debian.org/802211
Like, I have a passwordless root account to lower security and nuisance (different threat model, right?) 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. |
Is your feature request related to a problem? Please describe.
Both
rescue.service
andemergency.service
will try to drop to aroot
shell. If theroot
account is locked then you'll get an error messageCannot 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 theExecStart
option.Neither are good solutions or very secure.
Describe the solution you'd like
Instead, if
rescue.service
andemergency.service
dropped to a non-root user shell for a user that hassudo
asroot
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 couldsudo -s
toroot
.So, maybe the
ExecStart
line in/lib/systemd/system/rescue.service
for/sbin/sulogin
could look something like:And
/etc/admin.conf
would have: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:
The text was updated successfully, but these errors were encountered: