[cap-talk] Capabilities - the rub, an account, base functionality
Jed at Webstart
donnelley1 at webstart.com
Sun Nov 26 15:16:04 CST 2006
At 10:07 PM 11/21/2006, John McCabe-Dansted wrote:
> > 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
I agree with Marc Stiegler's criticism of 'popular' (comparable to
capability systems?) ACL systems above. I believe the approach described
below (which I am often the admin for) is so broken as to be almost
completely worthless. When considered in the context of network
communication I do consider it worthless.
>In practice this is commonly achieved by asking the sysadmin to give
>Sarah your access. Although this habit has considerable overhead, it
>also has some advantages as the sysadmin should be aware of the
>security implications of delegating certain rights and advise the user
>as to which exact rights they want to delegate. This would also allow
>us to find out who misused the right, either directly or indirectly by
>setting up a proxy in violation of company policy.
I don't understand the last sentence above.
>It seems like the information "which user actually did the `bad'
>access" is useful, and could be acheived in a cap system by having a
>trusted broker that logs accesses, and that you can send objects via.
>You can send the cap to Sarah via the broker, and if Sarah misuses the
>cap you can get the broker to verify that it was the wrapped version
>sent to Sarah that was misused. If you had a legitimate reason to
>delegate the authority, you don't get fired.
The above "broker" to get capabilities safely labeled as to their
delegation path is essentially what I described in a previous message:
At 06:50 PM 11/21/2006, Jed at Webstart wrote:
>I was suggesting that we could do better.
>We could insure that only Bob can access what Tyler delegated
>to Bob and only Sue can access what Alan delegated to Sarah
>who delegated it to Sue.
We could discuss implementation details, but the basic idea is that
I want to be able to communicate a permission to you as a capability
in such a way as to insure that:
1. If it is accessed in future it faithfully records that I
delegated it to you, and
2. Only you (initially of course) can access the delegated capability.
Regarding Alan's comment:
At 09:21 AM 11/22/2006, Karp, Alan H wrote:
>Who is going to enforce that? Not Tyler. He doesn't see the request.
>Not Bob. He wants Fred to have access without anyone else's knowledge.
>Not Jed. He doesn't have a trust relationship with Bob. I'm all for
>preventing accidental leakage of rights, but I don't believe you can
>prevent purposeful transfers.
I'm a bit lost on the above as to where Fred got into the act. However,
I think I'm clear on what I'm suggesting and basically how it can be
achieved. In my imagined scenario Tyler wants to delegate a
permission to Bob in such a way as to insure that Bob is confident
that he is the only one who can access the initial capability that
he receives. Bob can of course proxy or otherwise even directly
delegate (with the base capability communication mechanism)
the capability that he receives labeled as Tyler -> Bob. However,
without Bob's permission (e.g. delegation back) Tyler cannot
access this capability.
>The broker could be designed to tell the owner who the cap was
>officially delegated to. Of course one could, against company policy,
>hide the fact that the cap was delegated by using a proxy. However
>this would rightly mean that we would be in trouble, perhaps even if
>the cap isn't misused by Sarah.
Exactly. I believe this approach adds value to the base capability
mechanism that would help mollify those who are adamantly anti-capability
(e.g. Lampson? Gligor/Huskamp). I think it could also be useful in
cases like that of the HP scandal. I believe it would allow simple
user/process delegation as we know is possible in any case (my
inalienable right to communicate permission, what others refer to
as communicating conspirators) but still allow the person (or process)
wishing to do the delegation to do so in such a way as to properly
label accesses to the delegated capability as being from the delegated
I don't believe a broker is needed for this functionality. I believe, for
example, that this could be achieved through cryptography for
capabilities as data - though of course at the cost of increasing
the size of the capability at every delegation and perhaps with
more handshaking overhead.
I'd like to discuss this Friday at HP so we can get some face to face
time on this basic topic - what the functionality is, whether it provides
added value, how it could be implemented in various contexts (e.g.
with descriptor based capabilities, with capabilities as data). At this
point I don't know of a way to implement such a mechanism without
at least going back through the server of the capability to get the labeling
done. Perhaps others have ideas.
One thing I'd like to mention in this regard and for this discussion is
what I consider to be the essence of the capability mechanism. I know
I've mentioned the "communicable permission token" idea before, but
I'd like people to consider it in light of an ACL based implementation, e.g.:
I believe it's vital to distinguish the semantics of capability communication
from how it's implemented. If, for example, it was felt important to keep
track of capability delegations and the best way to do so was going back
through the server, then I believe it might prove effective to implement
capability communication by what;s referred to in the above paper
as "Encryption of Addresses":
Of course an "address" would be implemented as a public key,
but the basic idea is the same. If I have a capability (I could be
a person or process) and wish to delegate it to you, I send it to
the server with a request that it be re encrypted for you. The server
sends this newly encrypted version to you with an indication that
it came from me (to be bound to the token that I send to you in
my message to you). The server simply keeps a delegation list
for every outstanding capability.
While an approach like the above has some awkward aspects to
the implementation (perhaps these can be improved), I believe it
illustrates value that can be added to the base capability mechanism
(still faithful to the ability to always be able to delegate - as one
can do in any case with a proxy - but with greater efficiency of
access and better auditing/control).
In this regard I'm agreeing with Rob Meijer when he says:
At 03:17 AM 11/22/2006, Rob J Meijer wrote:
>Imho the question of accountability can not be focused purely on one
>single end of the delegation chain. I feel that you need to track both
>access 'and' delegation, or better yet implicitly cary the full delegation
>chain into any access in order to be able to trace the full delegation
>Only from the full chain of delegations and access can be determened
>where accountability must be layed. Thus each act of delegation should
>become an implicit part of the thus delegated capability imho in such
>a way that the whole chain can be reconstructed for auditing and IR purposes.
However, I think he and I part ways when he goes on to:
At 03:17 AM 11/22/2006, Rob J Meijer also wrote:
>Further by doing so you might match the accessing entity to that identified
>by the final delegation as a measure against capdata theft. That is,
>an entity should only be able to use a capability that was 'explicitly'
>delegated to it.
since of course we still have the access by proxy mechanism. We cannot
make the impossible possible, but I believe we can make what is possible
in terms of tracking intended delegation easy and convenient.
I do think there is win-win functionality available to us as long as we accept
what is possible and work with it. We're not going to get what most consider
as Mandatory Access Controls - simply because MAC doesn't accept the
simple proxy mechanism. However, we can allow discretionary access
control with better accounting/auditing than what one might imagine if
only simple 'traditional' communication of capabilities is considered - though
of course it's still a base object/capability mechanism for communicating
permission tokens that's still being utilized in any richer structure.
I believe that when Marc Stiegler writes:
At 03:29 PM 11/22/2006, Stiegler, Marc D wrote:
>To sum up, the list of feature you seek is supported to the same extent
>with caps as with acls.
he's right that one can achieve all that is possible with
object/capabilities, but the
sort of audit/control that is possible with acl mechanisms isn't
available with simple
communicated tokens. Perhaps by putting together generally accepted semantics
and perhaps even some implementations (e.g. as MarcS argues for CapWiki, which
I'd like to see become more widely used) we can improve the image of
perhaps beyond what was accomplished in the Capability Myths paper.
More information about the cap-talk