[cap-talk] Capabilities - the rub, an account
marcs at skyhunter.com
Sat Nov 18 11:03:59 CST 2006
Jed at Webstart wrote:
> At 10:53 AM 11/16/2006, Marc Stiegler wrote:
>> For the CapWiki, part of the design is, every time a user creates a cap
>> for delegation, we put an entry for the revoker and audit trail on that
>> user's home page, and include as much info as we can extract from the
>> context and the user's explicit entries about who/why/how long this cap
>> is for. This will give the user as much (well, actually, more)
>> understanding of what authorities he has passed out, and who he passed
>> them to, and what those people he gave the authority to should be held
>> accountable for, than he gets with any traditional popular acl system.
> Regardless of any implementation status I'd like to explore this space a bit
> as I think it's coming close to "the rub". Let's suppose we have something
> like the above and compare it with a popular acl system - say Unix.
> To be specific, how about using my favorite Web object example:
> (I'd love to have some comparable capwiki examples to work with)
> and suppose I have the facilities that you note above - namely that
> I can at any time create new instances with revokers and some sort
> of audit trail (I'm not quite sure what this feature consists of, but I
> soldier on) available. I could, for example, create a Marc Stiegler
> instance of any capability that I might have, e.g. a read-only
> capability that provides shared access to other capabilities (like
> a directory) as above.
> I could create such a capability and send it to you in an encrypted
> message. Presumably you could store such a capability in your
> set of network capabilities. At that point it seems we have a pretty
> clear picture - I have the capability (owner rights, RW, etc. with a
> revoker for the capability I sent to you) and you have a RO instance.
More fundamentally, I would already have it stored in my searchable mail
system, and could easily store it in my set of bookmarks in my browser.
> I could also do the same with a few other people, e.g. Alan and
> At some point you might decide that you wished to delegate access
> to this capability. I presume that at that point you would create a
> new instance with a new revoker that you could send to somebody
> else - perhaps somebody working with you on a project. We all
> agree that this is possible in any case (cooperating conspirators
> and all), so why not make it directly possible and with controls?
There are 2 ways of doing this, one of which requires your involvement,
one of which does not. I believe the important conversation is about how
I delegate access to your file without your involvement.
The way I do this without your involvement is, I set up a revocable
forwarder on my machine. If I do a revocable delegation to Sarah, the
webkey I send to Sarah actually points at an object on my computer,
which when invoked, queries your computer, and forwards the answer to Sarah.
On an ACL system, I would build a "revocable forwarder" by building a
proxy with other tools. For example, since this is a read-only
authority, I could set up a web server pointed at your shared folder to
which I have read access, and give Sarah a username/password. Or I could
have a daemon periodically reading your file and emailing it to Sarah.
These are both services invisible to you, revocable by me, forwarding
> Alan and Tyler could do some similar delegations.
> This process could go on, with revocable instances of the permissions
> granted by this capability spread around.
> Now at some point I (who am the only writer) post some information
> to this object and some time soon I see this sensitive information
> in some trade rag - shades of the HP board scandal.
> I want to close the leak. How do I go about doing so? The first
> thing I would like to be able to do is to find out who has read
> this information. How do I do that? If I was to go to the
> server and look at logs (assuming I have access to such
> audit log information - seemingly a good idea for "my" object)
> I could presumably see what reads have been done to that
> object since I posed the information that was leaked. This
> log data might look something like:
> Read times Capability IP
> 10/15/2006 17:23:10 Alan -> Sarah -> John 188.8.131.52
> 10/20/2006 13:15:07 Tyler -> Bob ...
> 10/22/2006 23:17:45 Alan -> Sarah -> Sue
> 10/24/2006 09:24:16 Alan -> Sarah -> John
> Is this the sort of thing you had in mind when you suggest that
> with such a scheme one would have more information than one
> has in a traditional acl system (e.g. Unix)?
As you can perhaps tell from the more detailed description I gave of
implementation, the answer is no. You cannot see that Alan delegated to
Sarah. You just see 4 accesses, 3 from Alan, one from Tyler. The "more
information" to which I was referring was the bidirectionality of the
information: I would have more explicit knowledge of the fact that I
have read authority on your folder than I do in an acl system. With
acls, you can give me read authority on your folder and forget to send
me email telling me about my fabulous new source of sensitive data. Now
I have the authority without knowing it. With webkeys, if you forget to
send me the email, I don't have the authority :-)
It is still possible for me to have an authority I don't know about (by
having a filter store the email without my reading it, for example), but
it is harder for me to escape realizing what I've got. And, if I don't
want an authority, I can rid myself of it -- by deleting the email, in
this example. With acls, if I have a dangerous authority that I no
longer need, I cannot get rid of it without help!
> If I'm going to plug my leak, how should I go about it? It might
> seem from the above that John, Bob, and Sue should be my
> primary suspects. However, it seems clear from the way
> capabilities work that unless there is some identity binding
> taking place during delegation then I also have to consider
> Sarah, Alan, and Tyler as suspects. Really the only person
> I've exonerated from this log is Marc (or others that I've sent
> the first level capability to besides Alan and Tyler).
> How does this compare with an acl system? Presumably in
> an acl system with equivalent logging I would know which
> identities did the reading, whether John, Bob, and Sue or
> Tyler, John, and Sue, or whoever. In the acl system (never
> mind the question of whether such a system could be
> implemented across the Web/Internet) it seems to me
> we have more detailed and effective information.
If I have explained clearly in the earlier implementation comparison,
you see that it makes no difference whether you're using acls or caps,
you have no clue that Sarah is in the loop.
Indeed, you have made an assumption about functionality in acl systems
that is not present in any popular acl implementation. It is not
possible for the holder of a read authority to delegate that read
authority to another person using the acl system. Only proxying as I
described earlier is possible. Why? Because for me to give Sarah an
explicit read permission, I must have acl-entry-editing permission. If I
have acl-editing permission, I have de facto write authority on the
file, because I can use my acl-editing permission to edit the acl so I
can write. In your original example, it is impossible for me to add
Sarah as a reader on your file. But it is straightforward for me to
proxy for her.
So all these apparent differences between caps and acls do not exist in
practice. They are illusion. The way I share my read authority, in
either system, is by proxying.
> Have I got it right/wrong with regard to what's possible with
> DVH style capabilities? Could we improve an object/capability
> system so that delegated capabilities could only be accessed
> by the receiver of the delegated capability and not the sender?
> I'm sure that could be done with some effort. I don't know of any
> instance where it has been done. Any effort to do so it seems to
> me would start to get bound up in notions of identity, but perhaps
> to a rather limited degree that could still remain faithful to the
> base object/capability concept.
Once all the objects and all the people are proxying for each other,
identity is useless for anything except single-step accountability. In
the world as it stands right now, for people who intend to attack you
proxying is cheap enough to be swell, but it is not cheap enough for
everyday people to use to get their work done. Kevin Metnick could set
up a Back Orifice on your box for you to do plentiful proxying in an
eyeblink, but the admin who doesn't know how to install Back Orifice
will, in her honorable role of doing her job instead manually email you
copies of the file to which she has read-only access after her boss had
told her to keep you updated. Current security works great for
inhibiting work, but it is lousy for preventing cracking. Is this a
> In the above I was dealing with delegation to people. It seems to
> me that similar issues would arise when dealing with delegation
> to processes. In a descriptor style object/capability system I
> believe an over arching TCB could effect the appropriate labeling
> of capabilities as they were communicated. In a network system
> (e.g. wideword, capwiki) I believe a more sophisticated exchange
> mechanism would be needed. I can imagine one if both sides
> have public/private key pairs along the lines of the scheme in:
> Perhaps I should get a reaction to the above discussion before
> proceeding further.
Yes. One must assume proxying before one can start thinking about the
real questions, much less the real solutions.
More information about the cap-talk