You could just put your binaries up for the major OSs to access your data, and people could use them in a native context.
Alas, we're in the timeline without capability based security. where users can't just give a file to a program at runtime using a (powerbox) dialog.
Furthermore, capabilities are more fine-grained. Today an app will ask for your location and you get to choose yes/no. If you say yes, it has full access to the GPS forever until revoked, sometimes in the background. Give it network access and it has that forever as well, and it can send anything to anyone (including the GPS data you just gave it access to.)
Capability based security would allow you to give it access to the GPS for a limited time, or to give it access to a sensor spoofing service if it really needs that data. If you give it network access it would be for certain times, or it could only send data to a whitelist of servers.
Moreover you can restrict the app from sharing granted capabilities to other apps. Or vice versa, you can delegate apps to work on your behalf and share capabilities with other apps, which you can later centrally revoke or restrict.
It’s really a better security regime than what the major operating systems have ossified around.
And lest you think you can work around this by rooting your phone, an increasing number of actually useful apps refuse to run on rooted devices, "because security", and Google is actively helping this by making available an API that streamlines those checks.
Capability-based security is a good idea, but like all security technology, it only helps the owner of a device, and who is the owner of a device in any given context is a contested topic, with platforms, vendors, manufacturers and users all having a different opinion about it.
Sure, we all want that, but we’ve learned that trusting apps does not scale. Even if you like an app and trust it, it can be updated to break that trust. Capability based security puts you in control so you don’t have to rely on trust.
> But it shouldn’t be able to send that image to a destination unrelated to my use case.
Capability based security could do this, and you don’t have to trust anyone to implement that feature for you (or to not silently remove it via an update). You would create a capability that would require camera and network access. Any app that needs both resources could take such a capability and be restricted in where it can send photos.
Phones don't do capability based security. There's no way to say, here... you can have access to THIS photo, or this location, once, in an easy way.
On PCs, you have to trust the application to do what it says when it uses the system supplied dialog boxes to "open" files, etc. In a capability based system, that's not the case. The OS never trusts the application, ever.
"Give X permission to access Y forever" is not capability based security.
https://www.youtube.com/watch?v=kFRy4IwUNog
Phones do not do capability based security, they could, but they OS doesn't offer that as a possibility, we get the low rent knock-off imitation instead.
We keep layering more and more gloop on the web. It will always be a game of wack-a-mole.
It's like Windows requires TPM, but then gives itself permission to snoop at your files. Or we have oauth, but then github is cracked to reveal the private keys. And so on and so forth, etc. ad nauseam. The clowns at Microsoft, Facebook and Google simply can't be trusted. They've proven that time and time again.
Security is better obtained "via negativa" (to quote from Taleb). Be parsimonious in what you allow. Keep things simple. If you don't really need security, then don't have it.
Mobile operating systems (aka modern personal computing) say hello.
There is no capability security on the OS level.
Otherwise Android wouldn't have a malware issue and iPhones wouldn't need to be locked up against third party apps.
You know, the same way that you ask for code review before merging to prod.
I've liked Wikipedia on that topic already in this thread. Please take a look.
And for bystanders, here's the Wikipedia link: https://en.wikipedia.org/wiki/Capability-based_security
My reasoning was that it would be rude to link to myself, to a comment that showed up at this time just on the same screen as this one.
But I guess you're right. A link would not hurt, but make it more easy to discover the mentioned content.
>Otherwise Android wouldn't have a malware issue and iPhones wouldn't need to be locked up against third party apps.
Android malware is not as bad as what is possible with Windows malware. Over the years Google has been cracking down and working to remove permissions that apps can use without the user knowing. Unless the app has an exploit for the operating system it can't do much harm to you. iPhones have allowed for third party apps since the very first iphone a decade and a half ago.
That's not capability-based security: you have to do that whichever model is in use. The ocaps come in when you use dependency injection (aka "function call") everywhere to pass in rights to make use of resources. Neither Android nor iOS are meaningfully object-capability based.
No, that would be mandatory access control. Completely different concept.
Please remember from the first commented:
>Alas, we're in the timeline without capability based security. where users can't just give a file to a program at runtime using a (powerbox) dialog.
This is literally how Android already works today. An app can not read a random file from the system. It has to open a file selector and you have to select a file before an app is able to read it.
That's not implemented on the OS level.
Yes, it is. The Storage Access Framework is a part of the operating system.
Generally speaking, capabilities are not asked for; that would be a permission.
Capabilities can be used to implement permissions, but that's not what is usually meant by 'capability-based security'. Capabilities are essentially just inputs; a GPS-reading capability would be anything we can read GPS data from (e.g. a callback; or a pseudo-file handle; etc.).
Security is enforced by choosing who is given a capability (like a URL); we can get extra security by minting new capabilities, and revoking those which should no longer have access.
Permissions are not required to "do" things; they are enforced elsewhere, to determine whether that thing should succeed or fail. For example, giving out URLs to search engines, then trying to have the server reject requests that we don't want (AKA 'closing the barn door after the horse has bolted')
The operating system uses both capabilities and permissions.
Regardless, this is all implementation details and for the user it is equivalent. There is the same principle of least privilege where apps are limited in what they can do.
No, that's still wrong.
The Android framework uses something that goes a little bit in the direction of capabilities.
But the Android framework / runtime runs (by now) on an OS (Linux) that is not capability safe.
> Regardless, this is all implementation details and for the user it is equivalent.
No, of course not.
On a capability secure OS your mouse driver can't read the disk or do network request. Even if you would find an exploit in the driver.
That's a completely different level of security!
It's a fact that there is still no capability secure OS out there in broad use. (Fuchsia could be the first that brings this concept into mainstream. But this will take time. Also Fuchsia isn't as strict as it could be, for different reasons).
No, that are two fundamentally different concepts.
A capability is something that needs to be hold and passed to every call. If you can't show the needed capability (because you don't own it, in the sense that you're holding a special kind of object in your hands) you can't preform an action. On the very basic level: You just can't call a function because it needs a parameter of capability type.
This is fundamental different to permissions. Permissions are checked by the called code. You don't need to "pass a permission" alongside the actual action you try to perform.
Please read up at least the Wikipedia page as you seem to have some severe misconception about this topic: https://en.wikipedia.org/wiki/Capability-based_security
Capability based security means that applications are very limited in what they can do by default and need to be given capabilities in order to do something. Yes, one way to give an application a capability is by representing that capability by a token, but another way to give an application a capability is by giving it a permission.
If you want the term to refer to a specific implementation ignoring that it is identical from the end user's perspective then I'm fine in conceding.
> A capability (known in some systems as a key) is a communicable, unforgeable token of authority.
That's verbatim the second sentence on Wikipedia!
That's not "an implementation detail", it's core of the whole concept.
> Capability-based security is to be contrasted with an approach that uses traditional UNIX permissions and Access Control Lists.
> Although most operating systems implement a facility which resembles capabilities, they typically do not provide enough support to allow for the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system. A capability-based system, in contrast, is designed with that goal in mind.
That's completely wrong.
The whole point of capabilities is that they're unforgeable.
You can't mint a capability! You need to get it passed "form above". Nobody can create capabilities from thin air (not even the OS kernel).
But I'm coming to the conclusion that you're only trolling. You refuse to look at the facts and definitions, and just repeat the same nonsense over and over. I'm done here as I obviously can't help you understand this topic.
seL4 is just the core of a micro kernel. The hard part would be to build an OS around that.
What is the security model you propose?
With at least two examples, please. To help me understand.
https://en.wikipedia.org/wiki/Capability-based_security
For examples have a look at the "Implementations" section.
You explicitly give it permissions to access something: give it a document you want to edit, allow it to save a result at some location (without giving it an idea what else exists at that location), allow it to connect to certain hosts on the internet, but not others, politely decline a request to use your camera, etc.
Very much like you do with a web app running in your browser.
Your customer comes to the office comes and wants to use the printer while he’s there, so you use your capability to send them a capability that will give them access to the printer (b/w only still, they can’t get color because you can’t get color) for an hour. However their capability is restricted such that they will not be able to grant anyone else access to the printer
Take $5 from your wallet to pay for a sandwich. That bill is a capability.
You can't accidentally give away your car when you do it. You can easily delegate the giving of the $5 to someone else safely.
Example 2
Take a file on a floppy disk for an IBM XT and make a backup of it. You can hand that backup disk to anyone and your original is safe.
You can use that file with any random shareware disk from your user group meeting and in no way could it cause you any more loss than the disk in it is on.
A disk is a capability.
Example 3
You are asked your location. You reply correctly.
The answer does not allow you to be tracked forever.
Example 4
You have a 15 amp outlet. You can't take down the power grid by accident, nor burn down the house. The outlet is a 15 amp capability.
Don't get me wrong, WASM is a nice idea with some nice properties. But WASI isn't a real improvement to the status quo in general.
If you mean at the bottom of the wasm, the the answer is, those won't be legacy APIs. The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer.
If you mean that all Wasm engines today are implemented on top of traditional operating system APIs, then yes, that is how things will often work, but that's ok. What really matters is how the virtual platform works. We don't have to expose things like "the filesystem namespace" directly to wasm, even if it's present in the host. And if we don't expose "the filesystem namespace", then we don't have the associated problems, even if the underlying host has them.
What's that "cleaner foundation"?
Next thing is: POSIX is the legacy stuff. If it's there nothing will change.
And not even to mention that the stack is going to look something like:
Hardware >> Hardware emulating some ISA (e.g. x86) >> C abstract machine >> POSIX >> VM emulating some ISA >> "container" emulating POSIX >> WASM VM >> emulation of POSIX APIs >> legacy applications written for some ISA & POSIX
I call this construct "layers of madness"… ;-)
The goal is to build a new platform. Initially, that looks like adding layers on top of existing platforms (which, as you say, already have multiple layers). If we succeed, then we get to start taking out some of the layers.