3 ms·

> So how is dropping privileges done correctly to avoid getting killed by the user? I was wondering this too. What is the way to "correctly" drop privileges? I

> So how is dropping privileges done correctly to avoid getting killed by the user? I was wondering this too. What is the way to "correctly" drop privileges? Is it even possible to drop privileges within a process in a way that's immune to this?

jontro 6y ago
I guess you could fork first?
- jasonjayr 6y ago
  Fork then handle child/exec error codes appropriately.
  - usr1106 6y ago
    Right, if the child runs as the user, the parent still running as root can reliably handle the situation that the user killed the child. Don't remember having seen that. Well, sshd does it, but for more obvious reasons than handling signals.
- usr1106 6y ago
  Forking does not affect the possibility to receive signals, does it?
usr1106 6y ago
logged in into one of my machines via ssh. The daemon is running with all uids being 0 and full capabilities. Don't see how that would be dropping any privileges. On the other hand * The machine has no desktop user at the moment * The program was patched on 04-Nov, I guess addressing this issue.
- mnw21cam 6y ago
  The program only temporarily drops privileges while reading the user-supplied file. The rest of the time, it would have all uids as 0 and full capabilities.
skykooler 6y ago
Drop them in a subprocess, read the file and send the data to the parent?
ComputerGuru 6y ago
There is no “tried and true” method to drop privileges after you’re done with them; this has been a constant source of headaches and security issues for pretty much any app that needs to be started as root in order to xxx (eg bind to a low port, if we pretend that’s the only way) and then drop said privileges. The solution is almost always to use (or add) kernel constructs that would obviate the need to elevate in the first place, but they generally aren’t fine-grained enough so on paper it looks like dropping privileges makes more sense, though in practice it might turn out to be the bigger mistake.
dfox 6y ago
The more or less default way how to accomplish this (ie. setuid(1)) is immune to that issue. On the other hand it does not really drop privileges in the modern sense as the process can regain them at any time because it is still owned by root.
- jwilk 6y ago
  No, a privileged process can't regain privileges after setuid(2).
GoblinSlayer 6y ago
seteuid(uid) if you want to revert later.

jontro 6y ago

I guess you could fork first?

jasonjayr 6y ago
Fork then handle child/exec error codes appropriately.
- usr1106 6y ago
  Right, if the child runs as the user, the parent still running as root can reliably handle the situation that the user killed the child. Don't remember having seen that. Well, sshd does it, but for more obvious reasons than handling signals.
usr1106 6y ago
Forking does not affect the possibility to receive signals, does it?

usr1106 6y ago

logged in into one of my machines via ssh. The daemon is running with all uids being 0 and full capabilities. Don't see how that would be dropping any privileges. On the other hand * The machine has no desktop user at the moment * The program was patched on 04-Nov, I guess addressing this issue.

mnw21cam 6y ago
The program only temporarily drops privileges while reading the user-supplied file. The rest of the time, it would have all uids as 0 and full capabilities.

skykooler 6y ago

Drop them in a subprocess, read the file and send the data to the parent?

ComputerGuru 6y ago

There is no “tried and true” method to drop privileges after you’re done with them; this has been a constant source of headaches and security issues for pretty much any app that needs to be started as root in order to xxx (eg bind to a low port, if we pretend that’s the only way) and then drop said privileges. The solution is almost always to use (or add) kernel constructs that would obviate the need to elevate in the first place, but they generally aren’t fine-grained enough so on paper it looks like dropping privileges makes more sense, though in practice it might turn out to be the bigger mistake.

dfox 6y ago

The more or less default way how to accomplish this (ie. setuid(1)) is immune to that issue. On the other hand it does not really drop privileges in the modern sense as the process can regain them at any time because it is still owned by root.

jwilk 6y ago
No, a privileged process can't regain privileges after setuid(2).

GoblinSlayer 6y ago

seteuid(uid) if you want to revert later.