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

[Jonathan Adams]

(deleted CCs to individuals)

On Fri, Mar 23, 2001 at 12:09:41AM +0000, Robert Wittams wrote:
> On 21 Mar 2001 17:20:25 -0800, Ka-Ping Yee wrote:
> > On 17 Mar 2001, Robert Wittams wrote:>
> > > 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. 
> > 
> > You are right.  We hadn't updated this part of the paper sufficiently
> > to reflect our last discussion about visibility with Mark and Norm.
> > 
> > Here's the plan: what we had in mind, but failed to explicitly state,
> > is that each granting action produces a revocable forwarder that the
> > user interface keeps.
> > 
> > The inspection and revocation of privileges then operates at this level,
> > on the revocable forwarders that correspond to the granting actions the
> > user took.  Suppose i give capability C to an application X.  In the
> > course of doing its job X delegates some work to some module Y and
> > passes on C in the process.  When i inspect the privileges, i only
> > see X, not Y; i see that X has received capability C.  If i tell the
> > user interface to revoke C, the forwarder is erased and neither X nor
> > Y can invoke C any more.
> 
> Yep, thats what I thought would be good ( and practical).
> Unfortunately, it doesn't seem like there would be a way to show the 
> delegation if the delegator doesn't want you to know. 

The only delegation that matters is a capability escaping it's application's
sandbox.  If an application decides to create 20 different processes and pass
its capabilities around between them, it doesn't matter, since we will destroy
the entire set of processes when the application quits. (i.e. by destroying the
spacebank)

So all we need to make sure of is that an application can't pass out one
of it's capabilities to another process without the UI knowing about it.
This can be handled by making invocations go through a proxy that guarentees
certain constraints. (i.e. only weak capabilities and forwarders can be passed,
and forwarders are replaced with new forwarders attached to the invoked
process) 

With this, the UI can know about all capability passing that has a visibility
requirement.

- jonathan