5 ms·
Process owned by human-user fork(2)s and then exec(2)s suid program owned by program-user; program owned by program-user then does most of the work; but calls b
by derefr 3y ago
Process owned by human-user fork(2)s and then exec(2)s suid program owned by program-user; program owned by program-user then does most of the work; but calls back over a domain socket to program owned by human-user to get it to do things on the program-user’s behalf.
Picture: local DB client, remote DB server. Server can stream a file to the client for the client to write to disk. “On the same machine, as a different user” is just the trivial case of “over the network.”
- jcrawfordor 3y agoThis doesn't actually provide the benefit of application isolation though; if the software is malicious or vulnerable the as-user component could be as well. Remember that the biggest use case for application isolation is untrusted applications. Essentially any setuid-based approach to isolation requires a trusted developer using very good practices to remain secure, and that's why it's faded away.
- derefr 3y agoWhat's insecure about setuid if the setuid user isn't a privileged user? For example, a setuid-nobody program, shouldn't be any more insecure than a systemd service spawned as User=nobody, no? (Also, implied is that any untrusted logic lives in the spawned program, while the "client" program is simple and auditable. As I said: like a database client vs a database server. Or how about: like a client that wants to print something, vs. a print server embedding untrusted printer drivers!)
- dathinab 3y agolike I sayed: hacks