3

There are commands (poweroff, reboot, etc.) in Linux that can be executed without root privileges in normal session, but need root privileges if they are executed in SSH session. I'd like to know two things:

  1. What is the purpose of this (why)?

  2. How is this actually implemented (how)?

4

First off, do note that this is not universal behavior. Not all Linux systems are configured this way, and in fact I can't name any distributions that do configure things this way by default without doing some serious research. In most cases, any given Linux system will either require root privileges regardless (this is what most systems do), or will let anyone in a particular group do it, or will just let everyone do it (though this is rare, as it's a pretty significant security hole allowing for a trivial DoS attack if a network service is compromised).

Why?

The why is pretty simple, it's very easy to accidentally shut down the system remotely when someone is trying to use it. By requiring either physical presence at the console (what you're calling a normal session) or proof of authority over the system (by authenticating via sudo to get root privileges), the system is making it much more difficult for such a situation to happen. The implication is that by being physically present at the system or providing root credentials, you have sufficient authority that it doesn't matter if someone else is using the system.

How?

This is somewhat more difficult to answer without knowing a lot more about the system in question, but a couple of methods come to mind:

  1. You can do some rather neat trickery with filesystem capabilities to allow for this, but you have to redo this every time the commands get updated.
  2. In the case of systemd, shutdown, reboot, and poweroff are all provided by systemd, and end up being equivalent to various systemctl subcommands. Because of this and the session tracking done by logind, it should be possible to impose restrictions like this pretty easily.
| improve this answer | |
  • 1
    The “How” is actually quite easy: PAM. Different services (like sshd) have different configuration. You can view them in /etc/pam.d. That’s how the system can know where the login came from. That’s also how Systemd does it. – Daniel B Jan 26 '18 at 11:45
  • @DanielB PAM is involved regardless, but other than controlling the capability bounding set in the first case I gave, it really does no more than the classification part of things. – Austin Hemmelgarn Jan 26 '18 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.