[cap-talk] Capabilities - the rub, an account
gmatht at gmail.com
Wed Nov 22 00:07:13 CST 2006
> 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
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.
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 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.
John C. McCabe-Dansted
University of Western Australia
More information about the cap-talk