[dathinab]

the problem is "just that" is not good enough

because programs often to need to have part of the capabilities of the user which started them, just a very well controlled subset of them, something which the UNIX model can't properly represent (through you can hack it on-top of it)

There is also the problem of having by default "owner-user owner-group other" as permission sets for files and executable. This works if others is "other humans" (assuming it does work, security issues on shared systems based on that where not uncommon). But this works much less if you want to protect users from rogue programs because then "other" tends to be far to permissive.

[derefr]

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]

This 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]

What'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]

like I sayed: hacks

[atahanacar]

If everything is a file, and files can have permissions, then you can simply allow the "program user" access to those files using groups.

[jcrawfordor]

The group model is far too inflexible to make this realistic... A file can only have one group, and people use more than one application. ACLs are available on Linux (although seldom used) and help to address this problem, but the ergonomics are very poor. Since ACLs don't address the issue of syscalls, IPC other than file based, etc., It hasn't really made sense to make them the focus or application isolation efforts. The kernel namespacing and capabilities features are a lot more attractive for this use and are more similar to the historic approach of chroot... But the tools still aren't great.

[atahanacar]

>A file can only have one group, and people use more than one application

But users can be in multiple groups. You can have files with groups like "graphics, audio" etc. and give access to the application users by adding that user to the relevant groups.

>IPC other than file based

This isn't UNIX model though, is it?

Though I agree with you. Given the current state of programs, file permissions aren't enough for isolation.