> Isn't this now the standard reality for most desktop and mobile OSs?
Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities.
Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail.
Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation.
> Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless.
The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it.
There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers.
There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.
Clearly if reasonable security is a goal default trust should be restricted. Minimum trust thresholds should be distinct from sometimes-needed trust which should be delineated on a per-item/per-session/temporally restricted basis.
Currently the way the web works, 1st party user downloading almost any 2nd party file means a 3rd party app of user-defined identity starts and reads the 2nd party file from a 4th party server in a 5th party format running on a 6th party OS with a 7th party network, 8th party browser and 9th+ party certificate chain in an unknown filesystem context. What is wrong with this picture? You can't establish trust in this context. All you can do is establish boundaries for failure.
Modern history has shown that this tower-of-crap™ approach is the most commercially expedient means to distribute new functionality to general computing devices. I would argue that the path forward in general computing is therefore to work on processes to enhance and apply those restrictions using improved architectural decisions at the interface level combined with CI/CD processes that automatically apply them.
In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.
> In short: stop asking the user, just design the system to grossly limit the scope and impact of any damage.
Yep. This has to come from OS vendors and while iOS and Android took some steps in this direction they're still basically POSIX about it instead of capability-based.
There's also a really unfortunate trend where apps want to be the entire user interface for everything. Manage the SMSs, be the camera and photos albums, handle payments, etc. This breaks all security guarantees by the OS.
> A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail.
I'm not an expert on iOS. From reading their latest security guide and a bit of wikipedia I think the following is true:
* iOS uses the ZNU kernel, a Mach derivative with BSD POSIX environment with traditional POSIX processes, ipc, filesystems, and networking.
* iOS implements runtime security by process/user-id separation and ACLs on system and inter-process APIs. The ReplayKit uses a similar idea by giving an app a handle on a single recording session, but it's implemented on top of the POSIX framework. For contacts it's clearly ACL based and either an app has access to all contacts or none whereas a capability system would allow a particular form of access to a single contact.
Capability systems are implemented by a kernel enforcing capabilities as the sole method of interacting with other objects in the system. There is no generic open(), connect(), read(), or listen() although there are similar methods on certain capabilities processes can hold.
For example, the user could provably give one contact to an app which was further allowed to share that contact with a third app under certain circumstances e.g. "schedule a call to Mom next Thursday" which would involve granting a scheduling app a capability to initiate a phone call but only to the number in the particular contact within a certain time window, by granting a re-grantable capability to the phone
number (and maybe display name) subfield(s) of the Mom contact, which the scheduler would hand off to the phone dialer at the desired time. This is a mildly contrived example because of the complexity of generating the specific capabilities necessary to accomplish it, but it should give an example of what is possible to do securely with a capability system that would be difficult or impossible with traditional ACLs.
I'm not sure how things are implemented on the OS level, but the high-level view from an app developer is this:
Apps are heavily sandboxed on the app bundle level. Any code that's installed from the App Store in an app bundle has no way to access the filesystem outside of its sandbox. There is no "access the file system" permission like on Android or on desktop OSes.
Inter-app communication is extremely limited. There is no way for an app to launch a process in another app bundle. When you open a file from the system Files app, your app gets access to that file only.
There is a small handful of high-level APIs that allow inter-app communication, including a URL handler, and a "share this file" dialog box, where you give the OS a file URL and the OS lets the user pick another app and the OS grants access to only that file to the other app. There are also some very narrowly-defined APIs for audio plugin-type data stream integration (which is gated by App Store approval)
There is no OS-mediated way to share live objects (you can share objects, but the receiving app just gets a copy of the state of it at the time of sharing)
For the OS-managed databases (photos, contacts, music etc), the exposed APIs vary wildly in how they manage permission
Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities.
Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to the entire viewer app. A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request and response is where all UIs (and most CLIs) fail.
Designing a safe and useful capability desktop/mobile environment is hard. Modern UIs and CLIs are just papering over the details of actual objects in the privilege system. Icons and filenames are only a human-readable representation of objects accessible with capabilities and so there's a disconnect between UI representation, user intent, and user interactions. Solving that means replacing arbitrary custom UIs with trusted, object-aware system UIs that reveal the actual state of capabilities and objects instead of a simplified representation.
> Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the button regardless.
The UI model would have to be significantly different with a lot of trusted components. Basically any UI element that can grant a capability to another app/process has to be part of the trusted system. That means a user-level app can't even ask for permissions to objects because it can't see them, know they exist, or refer to them in a way the system UI could grant a capability. Interaction between applications would be more like a smart clipboard; a user would open their camera app, take a picture, and grant a read capability to an app that's waiting for it.
There's a lot of 'convenience' lost in a pure capability system because there's no default trust in the good intentions of app developers.
There is a potential further development that allows convenience; formal proofs for application software that adheres to a particular data management policy. Say instagram wants to formally verify that photos taken automatically by the app (selfie button or whatever) can never be uploaded without user permission. Prove that the component for taking photos within the app drops all capabilities to the network and the main app itself before taking any photos; all it can do is fill up a particular folder/directory with new photos that are visible to the user, who can then trigger an upload (grant capability to a particular photo to the main app from a secure view of the directory) with another trusted interface. That trusted component could be granted a capability to the camera itself once the proof is verified.