4 ms·

That is sort of the opposite of a capability. In fact, files are capabilities exactly because you can hand off a file descriptor and, by virtue of that handle,

That is sort of the opposite of a capability. In fact, files are capabilities exactly because you can hand off a file descriptor and, by virtue of that handle, you grant access. File systems aren't actually capability based (generally, in practice) because you can 'ls' and 'cd ../'. Otherwise they could be. Dropbox Paper is a good example of a capability based system. Anyone with a URL can perform actions on a page, but there is no way to derive a URL without already having access to it, you must be told what it is. This is because the urls are sufficiently random so as to be unguessable.

trasz 4y ago
>File systems aren't actually capability based (generally, in practice) because you can 'ls' and 'cd ../'. Otherwise they could be. That's precisely how it works in FreeBSD (https://www.freebsd.org/cgi/man.cgi?capsicum https://www.freebsd.org/cgi/man.cgi?capsicum).
- staticassertion 4y ago
  "generally, in practice" There's also openat on linux. My point is that the general, practiced approach is not capability based.
  - trasz 4y ago
    It it’s not capability based, because Linux doesn’t provide necessary functionality. FreeBSD does, as explained in the man page I’ve linked to.
throwaway894345 4y ago
Are capabilities rotated periodically? Or how do you deal with leaked values?
- Rusky 4y ago
  It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. (One process can request that the kernel transfer it to another process, which I guess you might be referring to? I'm not familiar with Fuchsia specifically here but generally speaking capability-based designs sometimes let you "revoke" a capability if that is something you need, though that's not really something you would need to do periodically.) The Dropbox approach is sort of a fuzzy emulation of this, by necessity, because it's a public internet service.
  - throwaway894345 4y ago
    No, I just didn’t realize that it wasn’t useful to another process. I thought it was akin to a secret.
    - staticassertion 4y ago
      To be clear, the answer to your question is "yes, you need a way to revoke capabilities if you care about them leaking", and the user who responded to you is incorrect.
  - staticassertion 4y ago
    > It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. No, this is incorrect. Let's just quote wikipedia, > A capability (known in some systems as a key) is a communicable, unforgeable token of authority. communicable. It is practically the whole point that you can say "hey, here's a capability I have, now you have it". Yes, it matters deeply if a capability is leaked. To name something is to authorize something, in capabality land. No, you do not need to ask for it to be transferred. As with file descriptors in linux you can fork to delegate (or otherwise pass the handle around). Again, it is fundamental to capabilities that the capability is the authorization. Dropbox's approach is faithful. And, in order to deal with these limitations of capability systems, Paper supports ACLs as well as capabilities. I think it's going to be a huge problem if Fuschia doesn't, but I don't know what they do - certainly some sort of MAC is desirable.
- staticassertion 4y ago
  A leaked capability is indeed a critical failure. There are multiple ways to deal with that. 1. Revocation is pretty critical 2. Bounding of capabilities is great - "You have this right for N seconds", meaning that a leak is less devastating 3. Not relying on capabilities is the best option. Capabilities are amazing, and a wonderful access control system. Their main benefit is that you can very naturally implement extremely fine grained access control. The downside is that it becomes hard to reason about that access control statically. ACLs are bad at super fine grained access control, but they're great for "I can look at a policy and know what this thing can/ can not do". Layering ACLs and capabilities is a match made in heaven.

trasz 4y ago

>File systems aren't actually capability based (generally, in practice) because you can 'ls' and 'cd ../'. Otherwise they could be. That's precisely how it works in FreeBSD (https://www.freebsd.org/cgi/man.cgi?capsicum https://www.freebsd.org/cgi/man.cgi?capsicum).

staticassertion 4y ago
"generally, in practice" There's also openat on linux. My point is that the general, practiced approach is not capability based.
- trasz 4y ago
  It it’s not capability based, because Linux doesn’t provide necessary functionality. FreeBSD does, as explained in the man page I’ve linked to.

throwaway894345 4y ago

Are capabilities rotated periodically? Or how do you deal with leaked values?

Rusky 4y ago
It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. (One process can request that the kernel transfer it to another process, which I guess you might be referring to? I'm not familiar with Fuchsia specifically here but generally speaking capability-based designs sometimes let you "revoke" a capability if that is something you need, though that's not really something you would need to do periodically.) The Dropbox approach is sort of a fuzzy emulation of this, by necessity, because it's a public internet service.
- throwaway894345 4y ago
  No, I just didn’t realize that it wasn’t useful to another process. I thought it was akin to a secret.
  - staticassertion 4y ago
    To be clear, the answer to your question is "yes, you need a way to revoke capabilities if you care about them leaking", and the user who responded to you is incorrect.
- staticassertion 4y ago
  > It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. No, this is incorrect. Let's just quote wikipedia, > A capability (known in some systems as a key) is a communicable, unforgeable token of authority. communicable. It is practically the whole point that you can say "hey, here's a capability I have, now you have it". Yes, it matters deeply if a capability is leaked. To name something is to authorize something, in capabality land. No, you do not need to ask for it to be transferred. As with file descriptors in linux you can fork to delegate (or otherwise pass the handle around). Again, it is fundamental to capabilities that the capability is the authorization. Dropbox's approach is faithful. And, in order to deal with these limitations of capability systems, Paper supports ACLs as well as capabilities. I think it's going to be a huge problem if Fuschia doesn't, but I don't know what they do - certainly some sort of MAC is desirable.
staticassertion 4y ago
A leaked capability is indeed a critical failure. There are multiple ways to deal with that. 1. Revocation is pretty critical 2. Bounding of capabilities is great - "You have this right for N seconds", meaning that a leak is less devastating 3. Not relying on capabilities is the best option. Capabilities are amazing, and a wonderful access control system. Their main benefit is that you can very naturally implement extremely fine grained access control. The downside is that it becomes hard to reason about that access control statically. ACLs are bad at super fine grained access control, but they're great for "I can look at a policy and know what this thing can/ can not do". Layering ACLs and capabilities is a match made in heaven.