You grant them capabilities, a handle which permits access to a particular directory, one which allows network access (or possibly even further limited than that) etc.
No user, just a series of object handles which permit them to perform the task and nothing more.
Sure, but capabilities and handles are technical terms of art below the level at which regular users need to understand. The idea that an app is another person using your computer is not a terrible abstraction in terms of helping people make sense of what's happening.
Maybe. But they're a bad mental model for software developers because user based security is way more limited than what you can do with capabilities.
And they're confusing for users, too. Signal isn't another "user" on my phone. Its still me. I just decide what capabilities I grant it on the day. "Yes, you can use location tracking for now - but only until later in the day."
Maybe? I guess the difference is that with a capability object model (or similar arrangement) the _only_ way the application has to interact with the outside world is via those objects/handles it's been granted. There's no risk of escape because they only have access to the handles the process has been provided.
It's almost the opposite of a permission model in some ways, permission models restrict access to a global array of functionality where capability models allow access only to what's been provided.
Sorry, I appreciate the joke (really :) ) but I also worry that people keep trying to add the concept of "users" or an existing role or permissions model into capability-based systems when they're unnecessary.
You could maybe model or emulate a user in a capability system by providing the login's session manager an object with read/write access to the configured "user" directory, read and execute access to an applications collection, and full access to the root window. From there, when the user starts a new application it's given an object with access to a window created for it (by calling "createWindow" on the root window object, so it can't even do something like enumerate other windows or whatever), and whichever other requirements were configured as part of its install.
It's capabilities all the way down with no "user" involved.
A capability is not an identity. And the difference matters a great deal in how you build software that takes advantage of capability based security models.
Capabilities are often transient. Or in a capability based OS, capabilities are given to a process when it launches and the capabilities naturally go away when the program closes. "Who owns the capability" is the wrong way to think about it. But I'll lose this argument.
Because I suspect if you really want to, you really can think about all "permission systems" as identity systems, and shoehorn in users or something. This cognitive distortion is totally possible. My claim is that its a bad mental model. Its like if you mentally translate all programming ideas into assembler, or java or something, it would make it hard to properly understand and appreciate a lot of higher level programming ideas. Haskell's beauty doesn't make any sense if you mentally translate everything into java. There are programs you just can't write with this mindset, and you would be a terrible haskell programmer.
Its the same with capabilities. They're not user accounts. They're not identities. They can be transient or persisted. Fine grained or coarse grained. A capability can be a function argument - arguably the C FILE struct is a capability object. Or they can be a permission box. Its just, a bigger idea than identity.
You're so obviously correct in this. TBH I think the only reason the term "users" come up when it comes to isolating programmes from one another is because that was the only hammer Unix had, so it was coopted. The original point stands, the actual multi-user aspect is completely secondary and unnecessary to 90% of people. I'm the only person who uses my computer, but still I want to be able to isolate application 1 from application 2.
No user, just a series of object handles which permit them to perform the task and nothing more.