[formerly_proven]

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]

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]

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

[staticassertion]

"generally, in practice"

There's also openat on linux. My point is that the general, practiced approach is not capability based.

[trasz]

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]

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

[staticassertion]

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.

[Rusky]

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.

[staticassertion]

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

[Rusky]

I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzzy emulation"- you can in principle forge a URL in a way that you could never forge a file handle.

Obviously if you communicate the actual capability itself to someone you didn't intend to, that would be bad. But that's more of a question of API design- even fork is, in this sense, asking for the capability to be transferred. This is a very different problem than the one Dropbox has- no amount of random guessing, or side channel information leaks, or anything else like that, is going to land a capability in another process's kernel table.

[staticassertion]

Yes, accidentally sharing a capability is a leak. If I accidentally printed out a capability it would be 'leaked' and anyone who reads that capability now has obtained it an dcan use it.

> you can in principle forge a URL in a way that you could never forge a file handle.

Maybe it would be better to not talk about fs apis, because they're not really capability based, so I suspect that's the confusion.

The point is that if someone has a capability, they have that capability. There is no additional access control or checking in a capability based system. You absolutely have to consider things like rotation and revocation.

[throwaway894345]

No, I just didn’t realize that it wasn’t useful to another process. I thought it was akin to a secret.

[staticassertion]

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.