Insight gained from reading a paper titled "ACLs don't" that is really obvious in retrospect:
the confused deputy problem happens exactly because authority-based systems care about the authority of whoever directly performs an operation, and that intuition/model breaks when there's a *delegation*, i.e. with deputies.
It would be possible to deal with simple delegation, but it won't work when there are multiple levels of it or when there are complex delegation graphs.
This is beautiful and I've never thought about this before:
the convention we have in Unix to pass pre-opened stdin/stdout/stderr fds is not just a nice way to tell the program where to read its input from and output its result/logs to; it is exactly how capability passing should work in a capability-based system. This also is another reason why accepting an -o option (for "output file") is a bad idea.
Also, this is how socket activation works. systemd (or launchd, or inetd, or what have you) listens on a port or a Unix socket — because, being root, it has rights to. Then it passes a capability — either the bound socket fd, or an individual connection fd — when starting your service. Your service then doesn't have to be privileged, because it doesn't need to be able to open/bind the port/socket.
@bugaevc Got a link?
@bugaevc there was a problem with your link: http://waterken.sourceforge.net/aclsdont/current.pdf worked
@ConnyDuck @Tusky copy a link from some other toot (in this case it was from https://mastodon.technology/@bugaevc/101952678770861956) by long-pressing on it and paste it into a new toot
@xj9 yes; launchd even does this for Mach services. But that's not any news, what is news to me is the realization that this is basically capability passing!
@bugaevc Do you have a link to this paper? Sounds quite interesting.
@bugaevc Ooooh, what a lovely paper - thanks for linking to it.
It leaves me thinking that Flatpak portals are a good, but possibly roundabout way, of introducing capabilities for some operations. Good as in "stuff doesn't need to be modified too much".
@federicomena yes! Exactly! Basically, instead of having capabilities system-wide (...except we already have them in the form of file descriptors), we put each app into its own mount namespace to break the global file paths model, and then add into that namespace of an app to simulate passing capabilities.
@federicomena The thing is, while capabilities are cool and all, I haven't (yet) heard of a way to actually make them work at the user level. As the user, you really want named files and ACLs.
So the way you deal with this is you either overlay names/ACLs on top of capabilities, like Hurd, or overlay capabilities on top of names, like Flatpak, or put them side-by-side and sprinkle it all with endless hacks, like Darwin.
@bugaevc next on my list of papers is https://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf
@federicomena I know about Capsicum, but haven't seen this paper, thanks!
And just in case, you have read Capability Myths Demolished, right?
@bugaevc haven't read it, thanks!
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either! We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators. Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!