[cap-talk] Auditing and revocation in capability systems

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Wed Nov 22 07:46:23 CST 2006

Jed at Webstart wrote:
> I think the base issue ("the rub") the identity/acl people have with
> capabilities can be easily seen from the perspective of such a
> home/identity directory.  Suppose I'm a user identified to a system
> and accessing it through some sort of "shell" that's been given access
> to my "home" directory as above.  Then I create a new object, let's
> say a file, and store the most powerful capability that I receive for it
> in my 'home' directory.  Now I run a program that I give this capability
> to that file object and it communicates it to a program that deposits
> it into YOUR 'home' directory.
> At this point we ask ourselves, what auditing has happened?

If you are asking what auditing is possible, the answer is "as much as
the designer of the shell cares to implement". Assume that this is an
object capability system, and that the user's processes are each confined
by the shell. When the program tries to communicate the file capability,
it can only do so via a powerbox provided by the shell. This powerbox can
implement whatever auditing and revocation facilities are desired.

Note that the system may be a distributed cap system that uses some form of
capabilities-as-data for remote access, but it can still implement this
*provided* that the local subsystem can enforce authority confinement.

ISTM that the remaining issues are of how to give the auditing/revocation
facilities a user interface that makes it likely that they will be employed
effectively, not anything fundamental related to the expressiveness of
capabilities as an access control model.

David Hopwood <david.nospam.hopwood at blueyonder.co.uk>

More information about the cap-talk mailing list