[E-Lang] [EROS-Arch] Re: Interaction Design for End-User Security

[kragen@pobox.com]

Robert Wittams <robert.wittams@ic.ac.uk> writes:
> Also 5.4 revoking and reviewing privileges - this seems pretty
> complex.  It also means that the display server or whatever is
> drawing the arrows has the privilege to look at the capabilities
> that each app has and work out the designated object.  To do that is
> quite a high level of access to the internal state of keys.  Either
> that or there is some kind of intermediary indirection service which
> the arrow drawing thingy has access to (and which can revoke caps -
> by destroying indirections).  The problem with this is that the
> capabilities could have been passed in another way (not going via
> the indirection service). So it would not be able to show the entire
> state of the caps.  The smallest folder containing one end of the
> cap thing? I think that this will end up with hundreds of arrows
> going to the root of the namespace, or wherever "profiles" are kept.
> But still, I can't think of anything better ;-)

Revoking capabilities does require a proxy service, yes, and that
proxy service can retain records of which proxies are created for
whom.

Capabilities can be passed in other ways, yes; but if only the proxy
service holds capabilities to a particular component, then nobody will
be able to pass the capabilities in other ways.  Other components will
only be able to pass around capabilities to proxy objects.  If you
know which proxy objects have not been revoked, you know who can
interact with a particular callee.  If the proxy for a particular
caller starts getting abused, you can revoke that proxy, stopping the
abuse.

I'm very impressed with the conversation I'm reading here; I'm looking
forward to reading Ping's work!  Know wonder he wants to stay in
school...