[cap-talk] Security and languages talk

[Jed Donnelley]

At 07:29 PM 5/3/2008, Ivan Krstić wrote:
>I'm directing much of my recently-gained spare 
>time[0] towards a few  things I've wanted to 
>work on for a while, but haven't had the time 
>in  the course of my breakneck two years with 
>OLPC. One such thing is,  after giving a bunch 
>of high-profile talks about systems 
>security,  writing a short one about security 
>and programming languages. The Boston Lisp folks 
>invited me to give the talk[1] on May 27th, 
>so  the audience is a fairly clueful programming 
>crowd without any  necessary prior exposure to 
>language security and capability ideas.  I'll be 
>talking for 25 minutes: covering the basic ideas 
>and looking  briefly at things like E, Joe-E, 
>Caja and CaPerl. Questions for this crowd: * 
>Have you seen any _great_ short introductory 
>capability and    language security talks before?

The one that comes to mind for me is David Wagner's recent talk:

http://youtube.com/watch?v=EGX2I31OhBE
http://www.cs.berkeley.edu/~daw/talks/TRUST07.pdf

That was a 60 minute talk, but I think with a bit less emphasis
on Joe-E (while still speaking briefly and generally about object
safe languages) you might get something similar down to 25 minutes.

>What made them great?

I think there have been quite a number of now similar talks that
have covered the essentials and been good.  I believe at this
time it's almost to the point of essentially tuning some existing
talks to emphasize your interests while covering the essentials.

>* What do you think are things that I absolutely must cover?

For me the essentials are the value of POLA, it's simple
realization via capabilities as parameters, and the convergence
of OO programming and capabilities.

Rather than just state what seems to be general agreement
on this list, perhaps I can suggest some changes from elements
of recent past talks (e.g. like David's above) that I believe
will be improvements - perhaps for some discussion.

1.  I like the water tight ships compartments analogy.
Not new here, but there it is.  It seems to me an analogy
where it's easy to appreciate the value of the water tight
protection between the compartments while still allowing
explicit communication (e.g. doors, wires, pipes, etc.
between water tight bulkheads).

2.  I think the solitaire example for illustrating
the dangers of ambient authority can be improved.  I
suggest browser "display" software as an example.  E.g.
I recently found myself wanting to view a .flv (flash
video) file for the first time.  Yet another piece of
software that must run with all my privileges and might
be Trojaned.  There are several aspects of this example
that I believe are more compelling than the Solitaire
example:

   a.  I believe it's a common experience being pushed
to download and trust such software to view content that
others provide.  One can just argue that you shouldn't
play games - at least from untrusted sources - but
avoiding the use of third party software to display
(e.g. render) content is nearly impossible these days.

   b.  I believe an important aspect of this example is
that such software may be vulnerable from bugs even if
it's intent is good due to the possible presentation
of input crafted to exploit bugs.  By analyzing the
code it may be possible to craft an input file (e.g.
a .flv file in this case) that can result in a compromise
(e.g. data executed) and will result in an exploit
through such display software.

   I think just showing such a display and describing the
difference between having it trusted with ambient user
authority vs. having it restricted to only able to access
the file it is displaying and a display window is more
effective than the Solitaire example.

3.  Rather than use the simple cp vs. cat example to
demonstrate the difference between ambient authority
and explicitly communicated parameters (capabilities)
as authority, I believe the contrast between an open
file window and a power box example is much more
compelling:

     a.  It is more general and more powerful, applying
to nearly all cases where limited authority needs to
be communicated, and

     b.  It is a much more familiar instance that people
use all the time (open file windows) where I believe most
people can easily appreciate the value of the additional
control and POLA value obtained from the power box with
the *same* interface.  I find it easy to imagine using
the same familiar open file window interface but having
it control delegation of authority (power).

Text that I like to use with this example goes something
like this:

With the open file window the program has the ambient
authority to open and access (read, write, delete) any
file that you as a person have access to.  In the open
file window it is merely deigning to allow you some
input into which of the many files that it has access
to that you'd like to draw it's attention to.

By contrast with the same user interface in a power
box the program doesn't have access to any files.
It's asking you to grant it access to some file that
you'd like it to have access to in order to carry
out some task that you want it to do.

Likely could be better stated, but I believe the
contrast in security is stark between these two
examples with the same user interface.


>* If this was your first brush with the relevant topics,
>what could I say that would really pique your interest?

I believe asking the listeners to imagine a computing
(e.g. workstation, laptop, etc.) environment where they
can install software from relatively un trusted third
parties safely because:

      a.  The installer is only given write access to
a single new directory for it's purposes (e.g. untarred
files, a name space for writing content, etc.) and read
access to shared data (e.g. shared libraries), and

      b.  When such a program is run it is only given
access to it's one directory together with anything
that it is explicitly given - though a power box or
drag and drop, double click, etc.

That such an environment is not substantively different
in terms of user interfaces or really even APIs, but
it is much safer, more secure.

>Cheers, [0] 
><http://radian.org/notebook/maintaining-clarity> 
>[1] 
><http://radian.org/notebook/talk-language-security> 
>-- Ivan Krstić 
><krstic at solarsail.hcs.harvard.edu> | 
>http://radian.org 
>_______________________________________________ 
>cap-talk mailing list cap-talk at mail.eros-os.org 
>http://www.eros-os.org/mailman/listinfo/cap-talk

When you refer to the "tense and uncomfortable relationship
of programming languages and security", I'm not sure
what you are referring to.  We seem to now have many
examples where OO languages can be pushed all the way
to object safety.  When so pushed and with the use of
properly "tamed" libraries, it seems to me that
programming languages can have a positive and
symbiotic relationship with security.  Namely they
can provide an efficient means for enforcing the simple
parameter passing OO security of capabilities.

I think I agree with others, e.g. David Wagner, that
not explicitly bring up the "capability propagation
control myth" is wise.  However, I think it's important
to be ready to jump on any question about that topic
with a discussion of the Communicating Conspirators
discussion, e.g.:

http://www.erights.org/elib/capability/conspire.html

Namely to the effect that capabilities give one as
much control as is actually available and that
mechanisms along the lines of Horton can even
provide logging/auditing and after the fact identity
based control.

You can see an example of this sort of "loose
capabilities"/loss of control question at
50:37 in David Wagner's talk.

I like the phrasing, "Don't prohibit what you
can't prevent" that David W. uses.

However, I think it also may be worthwhile to discuss
here the notion that if, as David W. says, "If I
have a capability to Alice, then I can give her the
capabilities I have.  No restrictions on that."

I think there is a little subtlety here.  It may
be that the capability I have to Alice allows less
than unlimited communication.  For example, a Horton
tunnel that modifies capabilities in transit.
In such a case, even if the channel allows unlimited
two way data communication, it may be that the only
way to communicate a capability is via data
proxy.

 From my perspective the main point is that capabilities
can give you as much control as you can have with
any architecture.  It is the communication between
the entities that limits delegation, though of course
in any system communication to a third party (e.g.
maintainer of an access list) can also effect
access (e.g. delegation).

Sorry to drone on so much about this.  I suggest
listening to David Wagner's answer to that question
and thinking out what your own response to such a
question would be as it is a common question about
the object-capability model.

--Jed  http://www.webstart.com/jed-signature.html