4 ms·

Isn't the second approach a bit like when you send a special link to access the document? Which leads to the obvious "Anyone with the link can access the docume

Isn't the second approach a bit like when you send a special link to access the document? Which leads to the obvious "Anyone with the link can access the document"-ness with that solution? How do you avoid that situation - that if the link spreads, you effectively lose control until you realize and remove the link-based access of the document?

Natanael_L 11y ago
The link might as well be the document itself, a proxy into the computer of the person you shared it to. That's the point of capabilities. And that's why you want them to be revocable. You can make it a bit simpler by having the permission be a one time only token for requesting account specific permissions too. Works if you know how many people the link needs to be shared with (and ideally if you can give them separate links). But fails your goal if the link must be reused.
noblethrasher 11y ago
One of the maxims of capability-based security is: “don't prohibit what you can't prevent”. If I give Alice a capability, I can no more prevent her from sharing it with Eve than I can prevent her from being a proxy for Eve. This makes capabilities a more honest form of systems security.
kentonv 11y ago
Secret URLs ("anyone with the link can access") are a weak form of capabilities. They are problematic since they can't be traced nor revoked. A good capability system allows you to audit where the capability has gone and revoke it from specific parties without revoking it from everybody. A good capability system also makes capabilities harder to "leak" accidentally, while still allowing them to be transferred intentionally. For an example of capabilities that can't leak, look at Unix file descriptors. A process can transfer a file descriptor to another process via an SCM_RIGHTS message over a unix domain socket. The receiving process is able to perform exactly the same set of operations on the file descriptor as the sending process could, even if the receiving process belongs to a different user who doesn't have permission to open() the underlying file. Thus the FD is like a capability. File descriptors are not secret tokens -- they are easily-guessable small integers. But they cannot accidentally "leak" between processes because the OS explicitly involved in all transfers. (Of course, file descriptors still lack traceability and revocability, which a good capability system should support.)

Natanael_L 11y ago

The link might as well be the document itself, a proxy into the computer of the person you shared it to. That's the point of capabilities. And that's why you want them to be revocable. You can make it a bit simpler by having the permission be a one time only token for requesting account specific permissions too. Works if you know how many people the link needs to be shared with (and ideally if you can give them separate links). But fails your goal if the link must be reused.

noblethrasher 11y ago

One of the maxims of capability-based security is: “don't prohibit what you can't prevent”. If I give Alice a capability, I can no more prevent her from sharing it with Eve than I can prevent her from being a proxy for Eve. This makes capabilities a more honest form of systems security.

kentonv 11y ago

Secret URLs ("anyone with the link can access") are a weak form of capabilities. They are problematic since they can't be traced nor revoked. A good capability system allows you to audit where the capability has gone and revoke it from specific parties without revoking it from everybody. A good capability system also makes capabilities harder to "leak" accidentally, while still allowing them to be transferred intentionally. For an example of capabilities that can't leak, look at Unix file descriptors. A process can transfer a file descriptor to another process via an SCM_RIGHTS message over a unix domain socket. The receiving process is able to perform exactly the same set of operations on the file descriptor as the sending process could, even if the receiving process belongs to a different user who doesn't have permission to open() the underlying file. Thus the FD is like a capability. File descriptors are not secret tokens -- they are easily-guessable small integers. But they cannot accidentally "leak" between processes because the OS explicitly involved in all transfers. (Of course, file descriptors still lack traceability and revocability, which a good capability system should support.)