3 ms·
In a broad sense, this is the direction that Linux based systems are going. Specifically, replacing usages of setuid with sending commands to a process already
by gizmo686 3y ago
In a broad sense, this is the direction that Linux based systems are going. Specifically, replacing usages of setuid with sending commands to a process already running as root to execute on your behalf.
For instance, try running "systemctl stop sshd" as a non-root admin user. You will be prompted for a password, and ultimately able to do it; but no setuid binary is involved.
Instead, your command is sent to an already running daemon, which performs its own policy checks to see if you are allowed to proceed, before executing the action on your behalf.
At a glance, this sounds a lot like how setuid binaries work. The main difference is that setuid processes inherit a lot of state from the calling process. As a result, there have been a lot of attacks based on setting up the environment before calling a setuid program. The message passing approach removes that entire class of attacks.
In the case of a sudo replacement, you often want that state to pass through. However, a message passing sudo can still pass the state, and have the daemon set it when spawning the requested command. Since you can pass file descriptors between processes, you don't even need to take a performance hit (other than possibly increase overhead in the time before execution starts)
- nullc 3y agoThat message passing interface is still an attack surface, however... and one that is often a little harder to explore, the attacker isn't required to use the intended calling binary and can deviate from the protocol in arbitrary ways. Sometimes this has the effect of concealing the security properties. E.g. I had a quite unwelcome discovery that on Fedora a number of years ago where arbitrary users could reset the system time as a result of desktop affordances that were misplaced on a multiuser system and weren't locked out by traditional security measures. So, e.g. when some message-passing driven elevation thing adds intentionally adds new interface it may be pretty opaque to the system operator even compared to a SUID binary (which at a least ought to have commandline help!). Aside, the real merits of sudo are command filtering and logging. The way random desktops use it today is pretty much an abuse of the tool: might as well give the user the ability to execute suid copy of bash. :)
- lostmsu 3y agoTo my surprise I just faced a similar problem on Windows when I was implementing additional user-based isolation for my p2p cloud gaming service (the main one is VM boundary). Apparently when you create a process as another user on Windows by default the new process inherits parent's environment variables even though they belong to different users. That includes user-specific paths such as $TMP or $APPDATA. So most programs immediately fail because they try to write to the temp directory of parent's user. Solved this with a combination of LoadUserProfile and GetEnvironmentBlock.
- WirelessGigabit 3y agoSidenote: If you elevate as yourself you do NOT inherit environment variables!
- jojobas 3y agoIsn't setuid just another way to send a command to a process already running as root?
- uxp8u61q 3y agoNo, it's a way to start a process that will run as root. The distinction matters.
- HerrMonnezza 3y ago`s6-sudo` [1] is an alternative that does exactly this: connects to a running privileged daemon and asks it to execute a command. [1]: https://skarnet.org/software/s6/s6-sudo.html https://skarnet.org/software/s6/s6-sudo.html
- mid-kid 3y ago> You will be prompted for a password, and ultimately able to do it; but no setuid binary is involved. Polkit/pkexec is setuid.
- yrro 3y agopolkit is just the layer that takes care of answering the question "is the caller authorized to do this action". It's not setuid. pkexec is setuid, it gets launched as root, asks polkit, and then does the thing the user asks or exits saying "you're not allowed".