Yes, it is. Try and read GPS data without asking the operating system for that capability. Even if you call to native code there is no way to trick the operating system into giving you that data. Malware can't get it either because the security IS 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.
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.
> Try and read GPS data without asking the operating system for that capability
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.).
Capabilities and permissions are the same thing. The app needs a capability or permission for it to use an API. The whole point is that an app should have permission or the capabilities to the minimum amount of things in order for it to work.
Capabilities are needed to "do" things; e.g. the URL of a document is a capability to GET it (via HTTP, or whatever). Without a URL (capability), performing a GET doesn't even make sense.
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')
Android's binder seems to be exactly what you are talking about. A binder object represents a token for something you can send and receive transactions. You use binder to talk to LocationManagerService which lets you get the location. Android has a service manager and lets any app get the LocationManagerService. LocationManagerService itself does do the permission checks.
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.
> The operating system uses both capabilities and permissions.
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).
> Capabilities and permissions are the same thing.
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.
You are getting too hung up on the implementation details.
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.
We are using "capability" as a term of art here. Frankly, I'm not sure there is even a colloquial meaning of "capability-based security". Approximately no-one uses that phrase unless they're talking about capability-based security, the specific approach to managing access. In the same way that no-one calls functional programming "object-oriented programming" because "objects are just anything that exists and functions exist".
> 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.
> Try and read GPS data without asking the operating system for that capability.
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.
Yes, it is. Capability based security by definition just requires that apps have a list of a capabilities and those capabilities govern what APIs / resources it has access to. There is no requirement of dependency injection. That is an implementation choice.
You seem to be getting caught up with the implementation details. The whole point is that programs shouldn't be given overly broad access to the system. Access can be granted to programs by giving them capabilities. Whether that be from tokens or something else it doesn't matter.
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.
> 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.
I don't understand your point. In capability based security nothing prevents people from making up fake data if they don't have the capability for something.
I do not follow your logic. Anyone can define a data type { latitude: 100. longitude: 100 }. The operating system is not going to stop you from creating this object.
Such a made up object would not be accepted by other parts of a capability secure system as it would lack the actual capability (which is unforgeable).
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.
>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.