[cap-talk] What does the [defense?] security community really fear from capabilities?

[Jed Donnelley]

David Wagner wrote:
> [Sent privately.]
>
> Jed, I hope you won't take this the wrong way -- but in all honesty,
> I think you're off-base.  I also think fighting 20-year old battles is
> just not interesting.  Let's move on.
>
> I truly hope you won't take offense.
Not at all!  I appreciate the time taken.  No reason not to direct such 
communication
to the list as far as I'm concerned.  If I can absorb shots like those 
that James
Donald was firing off, I can certainly take a little well meaning 
criticism trying
to get me updated and on a better track for HotSec.
> This is intended as constructive
> feedback to help you refine the HotSec presentation, and it really
> isn't meant personally.  I'm sending this via private email so that I
> can speak bluntly and tactlessly.
>
>   
Honestly I don't see anything tactless in your message.  I hope you 
don't mind
my sharing my response with the list.
> To answer your question:
>
>   
>> I can't tell you how many times I've brought up POLA (which seems to
>> me a bit difficult to argue against) and object/capabilities as a technology
>> for dynamic management of permissions that can support POLA, only
>> to have people react along the lines of:
>>
>> "Oh, sorry poor sot.  Didn't you get the news?  Capabilities were
>> discredited in the late 1980s.  Didn't you hear that they can't
>> effectively do mandatory or discretionary access controls and
>> that even if they could they are overly complex and can't be
>> implemented efficiently?"
>>
>> I believe this is the view that is still ascendant.  Isn't it?
>>     
>
> Well, naah, I haven't heard that.
>   
I wasn't speaking figuratively or in the past.  I've heard multiple 
responses just along
those lines within the last year at LBL/NERSC.  The presentation that I 
listened to
just yesterday about how wonderful SELinux is for MAC security controls also
suggests that in at least part of the computer security community the 
views are
still very much user/ACL based.  Why?
> Two standard criticisms that I've heard are:
> (a) Fine-grained access
> control (of which capabilities are an example) are incredibly hard
> to use;
Of course if you try to do fine grained access control in a user/ACL based
system, they are incredibly hard to do.  If you do fine grained access 
control
with simple parameter passing (the object/capability model) then they are
very easy and straight forward to do.  It would be difficult and unnatural
to pass all of a user's permissions as capabilities to every program (though
doing so through a directory isn't all that difficult).
> (b) Capabilities require throwing everything we have out
> and doing everything all over again from scratch, which is nuts.
>
>   
There are at least two areas where access controls are relatively new 
and needn't
compete with existing systems - at the network level (e.g. mechanisms like
Tyler's YURLs/Web calculus and Widewords) and at the language level,
where objects are already pretty well entrenched.  I don't believe that we
need to throw out everything and start over again from scratch in either
of those areas.

In the operating system area there are definitely some legacy issues 
that will
be very difficult in a switch to object/capability based access 
control.  All the
interfaces to user/ACL functions (things like chmod, chgrp, etc.) will 
likely
have to ultimately be changed - though as we see with mechanisms like
PLASH and Polaris, there are transition strategies that can make the
transition not a step function and completely unbearable.

What is the alternative?  Living with:

Law #1: If a bad guy can persuade you to run his program on your 
computer, it's not your
computer anymore.

forever?
> Anyway, this all seems rather tangential for your HotSec presentation.
> Using the HotSec presentation to argue about capabilities in general
> or about "what went wrong 20 years ago" is not something I'd recommend.
> Personally, I'd stick to the technical content of the paper.
>   
I appreciate that point.  Perhaps that is the way we'll go.  It was in 
fact that paper from
20 years ago that I read recently that motivated the work that lead to 
Horton - as you
can see in the cap-talk archives.  However, I do think that certainly 
Microsoft's Law #1
and how commonly accepted it is as 'immutable' is relevant today.

It seems to me we need to provide some context for the Horton work.  Why 
did we
even consider such work?  It's meaningless in user/ACL based systems.  
Even if there
were object/capability systems around, what value would it have in that 
context?

May I ask, what would you suggest as a context to motivate/justify the 
Horton
work and suggest value for it?
> This is difficult to say over email as I worry that you'll take offense,
> but I wonder whether the HotSec presentation might benefit, tactically,
> from someone else who is not quite so close to the topic?  If I were
> hearing some of the stuff that's going across the mailing list while
> sitting in the audience of HotSec I might find it a bit off-putting.
>   
What I've sent across the mailing list has been deliberately extreme to 
test the waters.
The message that something more limited and, perhaps 'academic' has come 
across
loud and clear.  I'm working on something more along those lines.  MarkM 
will
chose what to present and likely make the whole presentation in any case, so
I'm just working on input.  I don't think you should be concerned.  Please
feel free to be open about your criticisms - at least with me.

That said, do you know anything about the folks at NSA, et. al. that are 
continuing
to work on the likes of SELinux?  As I mentioned, I've been somewhat 
involved
with some of these people, and as far as I can tell their views now are 
very much
like they were in 1987.  And systems are still be build to their 
specifications and,
to my thinking, they are woefully insecure as a result, both because:

A.  They assume unconfined communication, so any running program
can act as a collaborating conspirator with any other (authority is
freely moved around), and

B.  Programs continue to run with all the authority of a person
(user = me, or user=root) and so end up with way too much
authority.

The way I see the Horton work is that it is responding to one
of the criticisms of object/capability computing that we saw
in the various TCSEC criticisms, namely that it isn't possible
to track/log/audit who was responsible for what with capabilities.
Horton was a direct response to that criticism that came out
of that paper.  If we don't at least mention the criticism and
the paper then why Horton?

--Jed  http://www.webstart.com/jed/  (a bit hurried - I hope
that in my turn I don't offend).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070713/45539b33/attachment.html