3 ms·

> 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.

> 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.).

charcircuit 4y ago
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.
- chriswarbo 4y ago
  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')
  - charcircuit 4y ago
    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.
    - still_grokking 4y ago
      > 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).
- still_grokking 4y ago
  > 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. 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 https://en.wikipedia.org/wiki/Capability-based_security
  - charcircuit 4y ago
    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.
    - still_grokking 4y ago
      Dude, what's your problem? Are you trolling? > 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.
    - 4y ago

charcircuit 4y ago

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.

chriswarbo 4y ago
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')
- charcircuit 4y ago
  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.
  - still_grokking 4y ago
    > 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).
still_grokking 4y ago
> 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. 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 https://en.wikipedia.org/wiki/Capability-based_security
- charcircuit 4y ago
  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.
  - still_grokking 4y ago
    Dude, what's your problem? Are you trolling? > 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.
  - 4y ago