Skip to content
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

Open
imthenachoman opened this Issue Jan 30, 2019 · 7 comments

Comments

3 participants
@imthenachoman
Copy link

imthenachoman commented Jan 30, 2019

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:

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Jan 30, 2019

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.

@imthenachoman

This comment has been minimized.

Copy link
Author

imthenachoman commented Jan 30, 2019

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.

@cdown

This comment has been minimized.

Copy link
Member

cdown commented Jan 30, 2019

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.

@imthenachoman

This comment has been minimized.

Copy link
Author

imthenachoman commented Jan 30, 2019

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. :/

@imthenachoman

This comment has been minimized.

Copy link
Author

imthenachoman commented Jan 31, 2019

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.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Feb 5, 2019

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.

@imthenachoman

This comment has been minimized.

Copy link
Author

imthenachoman commented Feb 5, 2019

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.