[cap-talk] RE: OS security discussion, restricted access processes, etc.

Fri Apr 30 12:56:03 EDT 2004

Jed Donnelly wrote:

>              Confining this important facility to a single 
> new programming 
> language seems to me an almost certain path to obscurity.

We felt the same way when designing e-speak.  Hence, we built a system that only depended on using a specific protocol.  How you constructed the bits was up to you.  Of course, that meant we couldn't safely download untrusted objects into a running process, but we enforced a capability-like discipline between processes.  If you're interested, the most accessible source of information is http://www.hpl.hp.com/techreports/2001/HPL-2001-136.html.  All the gruesome details can be found at http://www.hpl.hp.com/personal/Alan_Karp/espeak/.

(Sorry for the delay in responding.  I've been blasting away to meet a paper deadline and am just now coming up for air.)

________________________
Alan Karp
Principal Scientist
Technical Computing Research Group
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp

> -----Original Message-----
> From: Jed Donnelley [mailto:jed at nersc.gov] 
> Sent: Monday, April 26, 2004 10:31 AM
> To: Mark Miller
> Cc: Norman Hardy; Eric Roman; Alan Karp; Jonathan Shapiro; 
> Marc Stiegler; Charles Landau; Mark Miller; Mark Miller; John Carlson
> Subject: OS security discussion, restricted access processes, etc.
> 
> 
> At 12:57 PM 4/20/2004, you wrote:
> >At 06:26 PM 4/16/2004  Friday, Jed Donnelley wrote:
> > > Since Shapiro and Miller's paper has been referenced so 
> much I kind of
> > > think they should stay in the list, but since I promised 
> to drop all the
> > > didn't opt in, I will only bcc them this last time.
> >
> >Hi Jed,
> >
> >Sorry, I missed that. I've heard the discussion has 
> continued past that
> >point.
> >
> >I'd like to opt back in. Please include both my email addresses:
> >markm at caplet.com and markm at hpl.hp.com. If it's not too much 
> trouble, could
> >you send all the correspondence that I might have missed? 
> (If it's just as
> >easy to resend the whole thread, that would be even better.) Thanks.
> 
> What's the distinction between markm at hpl.hp.com and the reply 
> address for
> this message, namely "erights at hp.com"?  Is there a connection between
> erights at hp.com or more generally HP and erights.org?  Can you clarify
> any relationships?
> 
> >Btw it's quite a pleasure to finally "meet" you. Your 1976 
> paper on DCCS is
> >excellent! Do you know if this is indeed the first proposed 
> distributed cap
> >protocol able to connect mutually suspicious nodes allegedly 
> operating local
> >cap systems? (See
> >http://www.erights.org/elib/capability/ode/ode-protocol.html 
> for refs to
> >some others.)
> 
> Hmm.  I've started looking at the above.  I'd be interested 
> to know the
> derivation of the term "vat" was in this context.  I can see 
> that I really need
> to do some exploring of the:
> 
> http://www.erights.org/
> 
> site.  It looks like there is some quite interesting stuff 
> there that I haven't
> explored adequately.  When it is said on, for example:
> 
> http://www.skyhunter.com/marcs/ewalnut.html#SEC3
> 
> "...Every time you turn on a word processor, play a game of 
> Solitaire, or 
> double click on an email attachment, you are executing mobile 
> code written 
> by someone you probably don't know and should not trust. Yet 
> we give Barbie 
> Fashion Designer and Christmas Elf Bowling the full power to 
> read our most 
> private documents, sell them on EBay to the highest bidder, 
> and then delete 
> all your files. Our grandchildren will laugh at how silly 
> this was, yet 
> today there is no choice. If Microsoft used E instead of 
> Visual Basic for 
> its application language, Word and Excel would not be vectors 
> for attacks 
> like the original Love Letter virus..."
> 
> I believe the issue we are discussing is being addressed 
> directly.  I'm not 
> sure why the argument is made there that a new programming 
> language is 
> needed to address this problem.  I certainly hope it isn't.  
> That rather we 
> can find a way to provide the basic needed facilities (domain 
> separation 
> and the ability to share resources on a need to use basis) in 
> many/all 
> existing languages and through many/all existing user 
> interfaces.  Confining this important facility to a single 
> new programming 
> language seems to me an almost certain path to obscurity.  Still, I'm 
> willing to push for whatever seems to be most able to solve the basic 
> problem, so I look forward to further discussions.
> 
> >-------------------------------------------------------------
> ---------------
> >
> >     Cheers,
> >     --MarkM
> 
> Hi Mark!  I just returned from a three day vacation.  It will 
> probably be 
> (it now is) Monday
> before I'm able to get plugged back into the 
> security/restricted access 
> discussion.
> 
> Nice to make your "acquaintance" also.  It's fascinating to 
> me to see how this
> area of computer security and more specifically OSs that can 
> support principle
> of least access has progressed (mostly seemingly not) over 
> the years.  I keep
> hopeful, but I've not found much to be encouraged about over 
> the years.  It
> seems like such an obvious base concept that I've indeed 
> found it somewhat
> distressing and embarrassing (for our profession as computer 
> professionals)
> that this underlying "problem" hasn't been corrected (with 
> corresponding
> corrections in user interfaces, documentation, human models, 
> etc.).  Still,
> we do what we can.
> 
> R.e. DCCS as first proposed distributed capability protocol.  
> I certainly don't
> know of any earlier.  As you may know I was motivated to 
> write the DCCS
> paper by three threads coming together:
> 
> 1.  The "RATS" capability based system that Charlie Landau 
> implemented at
> LLNL largely along the lines of the capability system from 
> MIT.  I worked on
> that system partly as the ARPA network technical liaison from 
> about 1974
> until about 1977.
> 
> 2.  The various resource sharing protocols like ftp, telnet, 
> remote job entry,
> etc. that I was helping to define for the ARPA network, and
> 
> 3.  Efforts like the TENEX RSEXEC that tried to share resources across
> a network by trapping system calls and doing resource specific network
> sharing.
> 
> However, I don't know of anybody in the capability area who 
> had proposed
> any sort of network sharing mechanism based on capabilities 
> as a generic
> resource.  I expect we would have heard of any such effort 
> and certainly
> any such publication.
> 
> Incidentally, I didn't see the Mach "reinvention" of network 
> capability
> sharing (they use the term "ports" ala Demos), e.g.:
> 
> ftp://ftp.cs.cmu.edu/project/mach/doc/unpublished/netmsgserver.ps
> or
> ftp://ftp.cs.cmu.edu/project/mach/doc/unpublished/netmsgserver.doc
> 
> in your bibliography.  Perhaps a reference to such a seeming internal
> document isn't appropriate?  It looked to me like they were 
> dealing with
> many of the same issues I faced in my DCCS design, though of course
> much later (1989) and without any apparent reference to earlier work.
> 
> By 1979 I had "converted" over to believing (as I still do) that 
> capabilities as
> data (not as kernel protected descriptors) is the appropriate 
> (simplest in
> terms of the kernel and therefore most secure [with no loss 
> of generality])
> method to use for capability systems - esp. distributed 
> capability systems.
> We went through about a year of debate on this issue 
> (~1978-1979) where
> I championed the descriptor model (as per DCCS).  I lost - and rightly
> so I believe.
> 
> It was that capabilities as data model that the "NLTSS" (sad name that
> forced out "Linos" through some Congressional level politics) 
> system (that
> I lead the design/implementation of - part of a larger 
> "LINCS" protocol
> effort) came to use, e.g. see:
> 
> http://www.webstart.com/jed/papers/Components/ (1979)
> 
> which you might find of interest if you haven't looked at it.
> I notice that you do have a reference to:
> 
> http://www.webstart.com/jed/papers/Managing-Domains/ (1981)
> 
> where I discuss various network capability models in a more generic
> sense.
> 
> I think my [with no loss of generality] statement above is perhaps
> the crux of the capabilities as data vs. as descriptors.  
> There are some
> abstract senses in which one can argue that capabilities as 
> descriptors
> add value, but I believe that in a practical sense (somewhat 
> like protection
> from passing bits through a covert channel constructed through shared
> resource consumption patterns is not, in my opinion, a 
> practical violation
> of confinement) there is no value added by capabilities as 
> descriptors.
> There is undoubtedly additional complexity - especially in the area of
> passing capabilities which is of course much more complex.
> 
> Oh well, I've delayed this message unnecessarily following 
> out this thread.
> I'll send it as it is and follow up as seems appropriate.
> 
> --Jed http://www.nersc.gov/~jed/  
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Type: application/octet-stream
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040430/77280b1b/AlanHKarp.obj