3 ms·

Every major operating system has a capability model (eg SELinux or Group Policies). Mobile operating systems have had capabilities from the jump, but still get

Every major operating system has a capability model (eg SELinux or Group Policies). Mobile operating systems have had capabilities from the jump, but still get hacked. (That being said, capabilities are great, we should use them and they do help. If you're not familiar with this pattern, look it up, it's worth knowing.)

ryanjshaw 3y ago
I don't believe that Linux capabilities are correctly named. They describe an ambient privilege, whereas capabilities represent explicit authorisation i.e. one invokes a capability to use it, and this is why entire classes of security vulnerabilities aren't possible in true capability-based systems. Unfortunately capabilities have long been misunderstood as equivalent to access control lists, and therefore ignored or misnamed due to the difficulty of building working capability-based systems Vs ACL-based systems. (ACL-based systems should be built on top of a capability-based core, and only apply to a smallest possible domain of objects - a single global namespace with an ACL-based access control mechanism is where the common security vulnerabilities of modern operating systems begin.) Smartphone permissions are also ambient privileges, but that's not the reason they get hacked: they get hacked because the operating systems are not designed around capabilities from boot and up, and have shared critical global namespaces with an ambient authority access control mechanism. Capabilities provide defense in depth, they don't make a system automatically unhackable but they do make it so that a critical attack path is highly unlikely to exist.
- maxbond 3y ago
  Hmm, I'm not sure we share an understanding of "ambient." Smartphone permissions are scoped to the app. It's been a while since I've messed with SELinux, but iirc, the rules can be scoped to an executable. Whereas in my mind, an ambient permission is scoped to a broad category, like a user or group.
  - mikewarot 3y ago
    Ambient here is defined as the programmer assumes that they don't have to ask permission, nor does the runtime, you can just open any file at will that the user is allowed to access, without restrictions. So if an image viewer is given permissions to access your photos, it includes a broad swath of permissions, including the ability to just corrupt them all. With a capabilities based system, the image viewer would get access to a single photo, or a folder of them, and perhaps read-only access, decided by the user at run time, instead of the system administrator at some earlier time, or the manufacturer as a category choice.
maxbond 3y ago
Re your edit, what disqualifies eg smartphone app permissions from being capabilities? As far as I can see - they literally are.
- mikewarot 3y ago
  A capability is essentially a handle to a file or folder, chosen by the user at runtime using a "powerbox" (much like a file-open dialog). The OS doesn't give access to anything other that the files chosen by the user, so no matter how confused or evil the program, it's not going to have unauthorized side effects. Permission flags just flags, not capabilities.
  - JimDabell 3y ago
    That’s how several iOS permissions work. For instance, you can trigger an image picker and receive a handle for an image asset without gaining permission to read the photo library.
  - nvm0n2 3y ago
    Capabilities are strictly less secure than hard-coded permissions, because capabilities can be given away by confused deputies whereas fixed permissions cannot. Capabilities also don't magically stop your app containing buffer overflows, SSO login problems, they don't make your users phishing-proof and in general they don't do a lot of anything. They're a useful API pattern that every OS already provides and has done for decades, but they're very far from a silver bullet.

ryanjshaw 3y ago

I don't believe that Linux capabilities are correctly named. They describe an ambient privilege, whereas capabilities represent explicit authorisation i.e. one invokes a capability to use it, and this is why entire classes of security vulnerabilities aren't possible in true capability-based systems. Unfortunately capabilities have long been misunderstood as equivalent to access control lists, and therefore ignored or misnamed due to the difficulty of building working capability-based systems Vs ACL-based systems. (ACL-based systems should be built on top of a capability-based core, and only apply to a smallest possible domain of objects - a single global namespace with an ACL-based access control mechanism is where the common security vulnerabilities of modern operating systems begin.) Smartphone permissions are also ambient privileges, but that's not the reason they get hacked: they get hacked because the operating systems are not designed around capabilities from boot and up, and have shared critical global namespaces with an ambient authority access control mechanism. Capabilities provide defense in depth, they don't make a system automatically unhackable but they do make it so that a critical attack path is highly unlikely to exist.

maxbond 3y ago
Hmm, I'm not sure we share an understanding of "ambient." Smartphone permissions are scoped to the app. It's been a while since I've messed with SELinux, but iirc, the rules can be scoped to an executable. Whereas in my mind, an ambient permission is scoped to a broad category, like a user or group.
- mikewarot 3y ago
  Ambient here is defined as the programmer assumes that they don't have to ask permission, nor does the runtime, you can just open any file at will that the user is allowed to access, without restrictions. So if an image viewer is given permissions to access your photos, it includes a broad swath of permissions, including the ability to just corrupt them all. With a capabilities based system, the image viewer would get access to a single photo, or a folder of them, and perhaps read-only access, decided by the user at run time, instead of the system administrator at some earlier time, or the manufacturer as a category choice.

maxbond 3y ago

Re your edit, what disqualifies eg smartphone app permissions from being capabilities? As far as I can see - they literally are.

mikewarot 3y ago
A capability is essentially a handle to a file or folder, chosen by the user at runtime using a "powerbox" (much like a file-open dialog). The OS doesn't give access to anything other that the files chosen by the user, so no matter how confused or evil the program, it's not going to have unauthorized side effects. Permission flags just flags, not capabilities.
- JimDabell 3y ago
  That’s how several iOS permissions work. For instance, you can trigger an image picker and receive a handle for an image asset without gaining permission to read the photo library.
- nvm0n2 3y ago
  Capabilities are strictly less secure than hard-coded permissions, because capabilities can be given away by confused deputies whereas fixed permissions cannot. Capabilities also don't magically stop your app containing buffer overflows, SSO login problems, they don't make your users phishing-proof and in general they don't do a lot of anything. They're a useful API pattern that every OS already provides and has done for decades, but they're very far from a silver bullet.