4 ms·

You know a limited kind of capability - file descriptors (or kernel handles). Those are just a number that allow you to manipulate some object in a defined way.

You know a limited kind of capability - file descriptors (or kernel handles). Those are just a number that allow you to manipulate some object in a defined way. You can give this number to someone else, and they can't make use of it at all, you have to go ask the kernel (using e.g. a unix socket and ancillary messages) to pass the capability to another process.

staticassertion 4y ago
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

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.