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

[Jed Donnelley]

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