[cap-talk] RE: OS security discussion, restricted access processes,
alan.karp at hp.com
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.)
Technical Computing Research Group
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
> -----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
> >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
> 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:
> site. It looks like there is some quite interesting stuff
> there that I haven't
> explored adequately. When it is said on, for example:
> "...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
> and the ability to share resources on a need to use basis) in
> 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
> 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
> that this underlying "problem" hasn't been corrected (with
> 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
> 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
> sharing (they use the term "ports" ala Demos), e.g.:
> 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
> 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
> 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
> 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
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040430/77280b1b/AlanHKarp.obj
More information about the cap-talk