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

[Karp, Alan]

Jonathan Adams wrote:
> 
> 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) 
> 

That's exactly the argument I made with e-speak.  In e-speak Beta 2.2 all
capabilities were held by the system.  The only way clients could use these
capabilities was by using names bound to them.  Since every request was
mediated by the core (TCB), it could see every transfer of access to a
capability.  In the e-speak product, this approach was replaced by SPKI
capability certificates, which can be passed out of band.  The only way to
control them is via the much-hated (by MarkM anyway) do-not-delegate bit.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Jonathan Adams [mailto:mshadow@ugcs.caltech.edu]
> Sent: Thursday, March 22, 2001 4:32 PM
> To: eros-arch@eros-os.org
> Subject: Re: [EROS-Arch] Re: [E-Lang] Re: Interaction Design for
> End-User Security
> 
> 
> (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
> _______________________________________________
> eros-arch mailing list
> eros-arch@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/eros-arch
>