[cap-talk] Lampson: Principle Of Least Privilege as damaging

Sun Apr 6 16:26:04 CDT 2008

Hi all,

I've read Lampson's depressing keynote too recently, and it had the  
effect of narrowing my vision down to these possible choices:
1. stop doing research on POLP and POLA (and maybe leave that to the  
real security experts, outside the academic domain)
2. stop doing research on security
3. keep on going anyway, without a short term perspective, just like  
before.

With a PhD on formalizing object capabilities, it was difficult to  
find a research position in mainstream security, and I did not find a  
suitable research project in a POLA or OCap related field.   
Capabilities are not (yet) frowned upon everywhere, but the overall  
impression seems to be that they are an unimportant and negligible  
part of safety research which is again a small part of security  
research.

My current research project ( http://www.esi.nl/short/poseidon/ ) is  
completely mainstream. I keep looking for ways to integrate object- 
capabilities into the project though, because I could not throw all  
that good stuff away even if I wanted to. Finding ways to combine the  
best in both approaches may be a way to raise interest and  
appreciation for object capabilities, trying the back door as the  
front door is closed.

Fred.

on 6-apr-08, at 22:14 CEST Jed Donnelley wrote:
> cap-talk,
>
> I decided it was worthwhile to go back through Lampson's keynote from
> Usenix 05 and find where and in what context he presented his argument
> against POLP:
>
> Lampson:
> "I think, for example, that the Principle Of Least Privilege has  
> done an
> enormous amount of damage to security because what it encourages
> you to do is to make everything fine grain and work out all the
> dependencies very carefully and it's too complicated.  You can't keep
> track of it.  You're bound to mess it up.  Even if you get it right  
> today
> it will be wrong three months from now.  Nobody will have the patience
> to ever look at it again because there's just too much of it.  So I  
> say
> absolutely not least privilege, absolutely not fine grain protection.
> Everything should be as course grain as possible because otherwise you
> won't be able to administer it.  That's a very unpopular position with
> most people.  I think there's a lot of empirical evidence that tells
> us now that it's right."
>
> <minor correction in the above from my former version - this was
> transcribed by me from the audio and I updated it slightly>
>
> http://www.usenix.org/events/sec05/tech/
> The audio: http://www.usenix.org/events/sec05/tech/mp3/ 
> sec05_keynote_small.mp3
> the charts: http://www.usenix.org/events/sec05/tech/lampson.pdf
>
> I think that keynote presentation is a good (though in my opinion
> wrongly biased) overview of computer security.  If the above
> statement is (and more generally Lampson's arguments are)  correct,
> then of course our whole effort toward POLA (e.g. with capabilities)
> is destructive and dangerously wrong.
>
> This is pretty fundamental folks.
>
> Lampson makes the above statement (at 14:30 in the audio) in the
> context of this statement from Hoare (page 10 of his charts):
>
> The unavoidable price of reliability is simplicity. —Hoare
>
> He argues (rightly in my opinion) that complex policy configurations
> inevitably result in less security rather than in more.  This is
> exactly my problem with SELinux.  As per the most recent discussion
> with Jonathan, perhaps I'm wrong about this (as Lampson is as well)
> and perhaps with automated tools for adjusting policies a mechanism
> like SELinux can be made to make a positive contribution.
>
> However (I think this is crucial), I don't believe that anybody
> argues that passing parameters to subroutines makes them more
> "complex".  Such parameter passing is an inevitable part of
> modularization.  Modularization makes computer systems less
> complex, not more complex.
>
> All the capability paradigm does is to allow parameter passing
> to do double duty.  To the parameter passing of names (designation)
> it adds parameter passing of authority.  The parameter passing
> itself doesn't become any more complex or any less needed for
> the communication of designation, but it does become more valuable
> in that at no cost in complexity it results in POLA (POLP).
>
> I hope some of you are able to allocate some time to review
> Lampson's arguments (above).  To me they seem fundamental to
> our efforts with capabilities.  These arguments aren't from 1987
> (as with P-1935 that argued that capabilities couldn't meet the
> Trusted Computer Security Criteria) but from a 2005 keynote from
> somebody who is consider a leader in our industry.  I certainly
> wish I had been there and could dispute his arguments.  Was
> anybody on this list there?
>
> Just to perhaps interest you a bit further, consider Lampson's
> argument about why we don't have "real" security (pg. 12 in
> his charts above):
>
>> Why We Don’t Have "Real" Security
>> A. People don’t buy it:
>> – Danger is small, so it’s OK to buy features instead.
>> – Security is expensive.
>> -- Configuring security is a lot of work.
>> -- Secure systems do less because they’re older.
>> -- Security is a pain.
>> -- It stops you from doing things.
>> -- Users have to authenticate themselves.
>> B. Systems are complicated, so they have bugs.
>> – Especially the configuration
>
> What I was recently arguing for in terms of "long term hope"
> is exactly this "real" security that Lampson argues will never
> be achieved.  He argues that instead it is right and
> inevitable (from the above) that we continue to patch and
> bail, what he refers to as "Resiliency" in his chart 11):
>
>> Resiliency: When TCB Isn’t Perfect
>> Mitigation: stop bugs from being tickled
>> – Block known attacks and attack classes
>> -- Anti-virus/spyware, intrusion detection
>> – Take input only from sources believed good
>> -- Red/green; network isolation. Inputs: code, web pages, ...
>> Recovery: better yesterday’s data than no data
>> – Restore from a (hopefully good) recent state
>> Update: today’s bug fix installed today
>> – Quickly fix the inevitable mistakes
>> – As fast and automatically as possible
>> -- Not just bugs, but broken crypto, compromised keys, ...
>
> I believe this argument is sooo wrong, but it seems
> to be the primary focus of computer security research
> these days and the reason that I see so little "hope"
> in the general thrust from this field.
>
> --Jed  http://www.webstart.com/jed-signature.html
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

---------------------
Fred Spiessens
IT Research & Consultancy
Evoluware
mailto: fred at evoluware.eu
http://www.evoluware.eu/