[cap-talk] Horton at HotSec '07: How broadly object/capability?

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Tue, 2007-07-10 at 18:11 -0700, Jed Donnelley wrote:
>   
>> I believe it's appropriate to start very briefly at the highest
>> possible level:
>>
>>
>> Computers are a wonderful invention.  They are very inexpensive little
>> slaves (with none of the ethical issues normally associated with
>> slaves -
>> at least yet) that can do our bidding.  To do so they must run
>> programs
>> that people write.  We now have this wonderful collection of people
>> who are writing all sorts of useful programs.
>>
>> However, the computer user community and market is currently
>> consumed by FEAR and LOATHING:
>>     
>
> This is an appropriate introduction for an inspirational sermon. You
> *can* get away with this style of talk at HotSec, but it better be
> viewed in hindsight as the best *technical* talk at the workshop if you
> ever want to be taken seriously again.
>
> The one certain way to permanently burn yourself with this audience is
> to frame an argument on polemics rather than facts.
>
>   
Jonathan,

Thanks for your useful comments.  What I wrote is just a set of first 
thoughts.  It does
represent how I think/feel, but of course there will be considerable 
discussion even if
MarkM decides to go with this general approach.  MarkM is the primary 
author of the
paper, and as such I consider him in charge of the presentation.  What I 
would like to
do (along the lines of what Alan K suggested) is to divide the talk into 
two brief
sections:

1 (or 2):  Something along the lines of what I just wrote - laying out 
the context
that motivated the Horton work - essentially to the effect that:

   a.  User based access control is broken, we need to go to POLA, at
        all levels, including language, network, and operating system.

   b.  An influential community did think that there were technical reasons
       for staying with user based access control and avoiding capability
        based access control, even though capability access control
        can support POLA - e.g. as per P-1935 - because they argued
        that capability access control had:

        i.  no control over permission communication (conspiring 
communicators),
       ii.  is unable to support Mandatory Access Controls - e.g. MLS, and
      iii.  is unable to track/audit/log who was responsible for what.

At the time there was no serious threat from Trojan horses - the problem 
that
capabilities and POLA solve by providing effective communication of 
permissions,
so it was a bit difficult justify too much work in support of 
capabilities and POLA,
particularly at a time when computer systems were enjoying terrific 
commercial
success - with the spread of home computers and later the Internet.

Now we well know that there is a serious threat from Trojan horses.  
Just look
around at the number of robot home computers.  POLA is the only effective
answer.

We also know that from the arguments above, i., and ii. are simply wrong.
Capabilities provide more effective control over communicating conspirators
(by providing for confinement which is the only effective control), and 
capability
systems can do MAC and MLS as effectively as systems with user based
access control e.g. via ACLs (though MAC and MLS seem a less potent
argument these days).

Horton now shows that iii. is also wrong.  We can have effective identities
and we can track responsibility for capability enabled actions and attribute
them to those identities.


There really is not technical justification for not implementing POLA
access management via communicable object references (permission
tokens, capabilities).  We should move to such access control
schemes in new implementations (e.g. at the network and language
levels) and begin the difficult work of transitioning to POLA
for our operating systems (e.g. with approaches like PLASH,
Polaris, and other such gradual transformations).


2 (or 1):  Describe Horton.  Though for us in the cap-talk community
it may not be so surprising (given our frequent discussion of revocation
mechanisms, membranes, and such) that only by using pure object/
capabilities one can implement effective tracking of responsibility
for capability enabled actions via identities, Horton succeeds in doing
so.  We can describe this as per the paper.


> I think your comment
>
>   
>> Public enemy #1 in this situation amounts
>> to Microsoft's (bogus) first 'immutable' law of computer security:
>>
>> Law #1: If a bad guy can persuade you to run his program on your
>> computer, it's not your computer anymore.
>>     
>
> is a good and useful point to make, because the rule is obviously wrong.
> But you better not call it "public enemy #1" unless you can point to a
> source for that statement. That's polemics, and this community HATES
> that sort of bullshit with a burning passion.
>
> Jed: if you proposed such a talk with me as a co-author, I would
> seriously review the talk because it very well might fall under the
> "best technical talk" category. If it did not, I would probably insist
> that my name be removed from the work.
>
>
> It is very important to me that MarkM be perceived with credibility in
> this community. Please work to support his long term success. Please do
> not damage that potential by alienating his colleagues.

I agree.  As I indicated, MarkM is in control.  One possibility is that 
I'm willing to
play the role of the extremist, arguing passionately for 
POLA/capabilities.  MarkM
can be seen as the reasonable implementor - demonstrating an elegant and
somewhat surprising mechanism with E, etc. in response to my challenge, but
staying somewhat above the fray.

MarkM did do the Horton implementation in response to my challenge.  The
motivation was as I suggested.  It does seem to me that it answers a 
technical
challenge to object/capabilities and POLA.  How effective the argument that
it is the "last" impediment and therefore significant is certainly open 
to question.
I can just throw it out there, support it, and see where the chips fall.

Regarding how passionate to make the argument (polemic) and how
strong the technical argument needs to be - well, I appreciate the
input.  I believe the Horton implementation stands on it's own for
what it is.  I don't believe there is any question that it succeeds in
achieving it's requirement.   Of course it's up to others, history,
etc. as to how important/relevant that is.  I don't claim any great
relevance.  I personally doubt that any practical implementations
of Horton-like mechanisms will be put into place soon.

So, regarding:

> You *can* get away with this style of talk at HotSec, but it better be
> viewed in hindsight as the best *technical* talk at the workshop if you
> ever want to be taken seriously again.
>
> The one certain way to permanently burn yourself with this audience is
> to frame an argument on polemics rather than facts.
The technology of Horton, while I think a bit surprising - especially to 
those
outside the capability community - is pretty straight forward though I 
regard
it as at least clever.  As a technical demonstration I consider it 
important.  I
don't know what the other technical presentations will be, so of course 
I can't
judge it in that regard.  However, I suggest a "go for it" approach.  
Let's try
to shake up the world and see what happens.  As I say, I can be the fall
guy (unlike MarkM, I have little to lose) and be the one putting out the
polemics - though as I say I believe them and hope others will review
them to insure that I'm not saying anything that is fundamentally untrue.

I'll respond more regarding the effect of the Orange book period on
POLA in response to David Hopwood and Jonathan in a separate message.

--Jed  http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070711/000285f1/attachment.html