[E-Lang] Summary for Practical Programming

Karp, Alan alan_karp@hp.com
Tue, 6 Feb 2001 08:41:16 -0800


I've been thinking about this issue over the weekend, always a dangerous
thing, and I think we also made a design decision in e-speak Beta 2.2 that
encouraged bad behavior.  In the case of starting a new process, we chose
the Unix default of giving the child all the parent's privileges and
requiring the parent to remove some before starting the child.  That leads
to careless programming where you don't bother to remove any of them.
That's just a bad default, though, and easily corrected.

A bigger problem was that we encouraged similar behavior by collecting
capabilities on key rings.  We had good reasons for introducing key rings.  

o We could ensure that the capabilities were presented as a set or not at
all.
o In the case of the mandatory key ring, we could be assured they were
presented on every access.
o Many tasks require a set of capabilities, which is nicely represented by a
key ring.
o It is easier to control the distribution of a single key ring than a set
of indivisual capabilities.

Two of these reasons are to make things more convenient and have no real
security implications.  

In retrospect, we should have looked for another mechanism to implement the
first two requirements.  The reason is that key rings encouraged bad
behavior.  Most people simply put all their capabilities on their mandatory
key ring, which had the effect of every operation being performed with their
full set of privileges.  As we well know, that's one of the major sources of
problems in today's systems.  The problem was mitigated by the fact that
only the access rights, not the capabilities themselves, got forwarded with
the request.  Still, the chance for error was greater because too many
permissions were activated.

This behavior was not what we intended; we thought that people would have
lots of keyrings, each for a particular purpose.  Perhaps we could have
avoided the problem by providing better tools.

_________________________
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: Karp, Alan [mailto:alan_karp@hp.com]
> Sent: Thursday, February 01, 2001 4:19 PM
> To: 'Mark S. Miller'; Bill Frantz
> Cc: Marc Stiegler; E Language Discussions
> Subject: RE: [E-Lang] Summary for Practical Programming
> 
> 
> No, you remember correctly, but it wasn't anything inherent 
> in e-speak Beta
> 2.2; it was a choice of a poor default, one that I argued 
> against.  This bad
> default is what you're thinking of.  It is one in which the 
> child is set up
> with all of the parent's privileges, and the parent must 
> explicitly remove
> those rights it doesn't want the child to have before the 
> child starts.  The
> details follow, but what I've just said summarizes the issue.
> 
> The question is what authority do you give a child process.  
> Clearly, when a
> child process is started, at the very least we want its 
> privileges to be no
> greater than its parent's.  We embodied this set of privileges in the
> "mandadory key ring", a set of capabilities presented on 
> every request, and
> a "protection domain" that gives a process names for 
> resources, including
> the names of other key rings that could optionally be presented.  
> 
> We guaranteed that the child's rights did not exceed the 
> parent's by giving
> the child clones of the parent's mandatory key ring and 
> protection domain.
> Unfortunately, this default behavior meant that the parent could only
> restrict the child's privileges by removing any keys from the 
> mandatory key
> ring and any names from the child's protection domain before the child
> started.  
> 
> A better procedure would be to start the child with no names 
> or privileges
> and have the parent add them explicitly.  The problem with 
> this approach was
> that the parent did not have names for all the keys on its 
> mandatory key
> ring.  (Some of them represented negative permissions, so we 
> can't let a
> process remove them from the key ring.)  Therefore, there was 
> no way for the
> parent to add them to the child's mandatory key ring.
> 
> The solution is quite simple.  Don't give a process a name 
> for its mandatory
> key ring.  That way only the system administrator can add 
> keys to it.  All
> other capabilities the process wants to present must 
> necessarily be added to
> another key ring.  Now the child can safely be started with a 
> mandatory key
> ring that is a clone of the parent's and the default 
> protection domain, as
> this state is the most restrictive one the parent is ever in. 
>  The parent
> can then pass additional key rings to the child or even add 
> keys to the
> child's mandatory key ring.  In this way, the parent can 
> restrict which of
> its rights the child has when it starts.  Note that the child 
> can obtain
> rights that the parent could get but may choose not to have, 
> a desirable
> property.  By adding keys representing negative permissions 
> to the child's
> mandatory key ring, the parent can restrict which rights the 
> child is able
> to get.
> 
> _________________________
> 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: Mark S. Miller [mailto:markm@caplet.com]
> > Sent: Thursday, February 01, 2001 3:02 PM
> > To: Bill Frantz
> > Cc: Marc Stiegler; E Language Discussions
> > Subject: Re: [E-Lang] Summary for Practical Programming
> > 
> > 
> > At 02:44 PM Thursday 2/1/01, Bill Frantz wrote:
> > >Marc - Thanks for trying to summarize things.
> > >
> > >At 02:15 PM 2/1/01 -0700, Marc Stiegler wrote:
> > >>6. We all agree that POLA is an inherent characteristic in 
> > the nature of
> > >>capability systems, and to the various extents that each 
> > individual in this
> > >>discussion knows the actual behaviors of these 
> > implementations, POLA is a
> > >>part of both E and EROS as actual implementations.
> > >
> > >I am not sure about this one.  I think some of the early 
> > capability systems
> > >did not easily support POLA.  (Where is my copy of Levy.)  
> > Certainly one
> > >could design a capability system where every call (by 
> > convention) passed a
> > >capability to the home directory.  I think a rewording is in order.
> > 
> > 
> > I hate to do this to you Alan, but I think you're our live 
> > representative of 
> > this family of systems.  From previous correspondence on the 
> > list, I have 
> > come to think of E-Speak2.2 firmly as a capability system.  
> > (Certainly much 
> > more so than SPKI or E-Speak-3.)  However, I recall there was 
> > something like 
> > an implicit inheritance of vast amounts of authority from a 
> > parent to a 
> > child, analogous to Unix's fork() or exec().  I remember it 
> > struck the rest 
> > of us as a gross violation of POLA, you didn't disagree, but 
> > said it was 
> > necessary to avoid confusing your target audience.
> > 
> > Does any of this ring a bell?  Does it sound right?
> > 
> > 
> >         Cheers,
> >         --MarkM
> > 
> > _______________________________________________
> > e-lang mailing list
> > e-lang@mail.eros-os.org
> > http://www.eros-os.org/mailman/listinfo/e-lang
> > 
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>