[cap-talk] Security and languages talk

[Jed Donnelley]

At 07:51 AM 5/4/2008, zooko wrote:
>On May 3, 2008, at 8:29 PM, Ivan Krstić wrote:

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

>One interpretation of the resurgence of 
>capability theory in the last  decade is this: 
>For a long time, capability theorists tried to 
>persuade security  theorists:  "Hey, you guys 
>really messed up, made some basic 
>factual  errors about capabilities in the 70's, 
>and then you all built careers  out of inventing 
>alternatives to capabilities which alternatives, 
>it  turns out, aren't necessary.". For some 
>reason, this didn't go over very well, e.g. [1].
>[1] http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html

Occasionally I get new insights from rereading 
such material.  In this case I realize the this from Boebert:

>   As a footnote, Bill Young  of the University 
> of Texas, Dick  Kain, and I  decided shortly 
> thereafter that a distributed protection state 
> was beyond the ability of the verification 
> tools of the time to deal with, and we dropped 
> the PSOS-inspired capability architecture for a 
> more direct implementation of the 
> Lampson  Access Matrix.  This 
> eventually  became  what is  now 
> known  variously as Type Enforcement or  Domain 
> Type Enforcement.   This evolution is document 
> in [2], which  also contains a useful bibliography.

had led me to erroneously conclude that Peter 
Neumann and PSOS also dropped the capability 
architecture.  (sorry to Peter...).  It seems 
that rather Boebert and Kain instead chose a 
different architecture for work into the 1990s 
that I think I need to read more about.  The 
incorrect date on the reference from the above message:

[2] Boebert, W.E.  and Kain, R.Y., "A 
Further  Note on the Confinement Problem."  Proc 
IEEE International Carnahan Conf. on Security Technology,  1966

as 1966 when it should be *1996* is also a bit confusing.

There is some odd stuff in those comments on the 
Myths paper, particularly in the second to last 
comment.  As others seem to be tired of 
'historical' discussions, I won't pursue that 
here, but I will note that those comments are 
from 2003, decidedly within this decade.
>(I love  the bit about the flaming sword.  That 
>sounds like Ross Anderson's  voice.) Sometime in 
>the early 21st century the capability theorists 
>started  telling programming language 
>researchers: "You guys have developed  these 
>wonderful theories of how to build and manage 
>abstractions and  guess what?  Your ideas can 
>solve security problems as well as  solving the 
>problems that you started out with.".

I think it's relevant to note that the "problems 
that you started out with." are quite similar to 
"security" problems in that object oriented 
programming provided for isolation of access for 
the purpose of limiting the potential for bugs.

>This was a much more popular pitch.  Security 
>had already become important to  programming 
>language theorists by then because of the Web 
>(i.e. the  Mass-Market Internet). So if I were a 
>programming language expert who had not yet 
>thought  deeply about security, my interest 
>would be aroused by the notion  that good 
>security can be implemented as an elegant 
>extension or re- use of my favorite 
>meta-abstractions.  This would come as a 
>pleasant  surprise, since I would have 
>previously conceived of security as 
>an  aesthetic horror -- scarring and crippling 
>my beautiful language, or  else imprisoning it 
>in a tiny cage -- to make sure that it 
>isn't  powerful enough to be dangerous. Regards, Zooko

All true.  The above seems to me the most 
important value of the OO/Ocap convergence.

However, that doesn't mean that the 'old' 
criticisms of capabilities (e.g. loss of control, 
inadequate auditing, etc.) go away just because 
capabilities are now visible in a language 
context.  I think it also important to note that 
not all the "new" value in capabilities for the 
Internet/Web come in the language form.  Waterken 
"Web keys" and other network capabilities as data 
(e.g. Tahoe File System capabilities) have 
nothing inherently to do with the language 
context.  Power boxes have nothing to do with the 
language context, but the realization that the 
popular "open file" window interface can be 
applied as a power box for control over 
authentication I believe is important for the 
improved perception of capabilities (e.g. Plash).

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