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

[Jed Donnelley]

At 10:07 PM 4/6/2008, Baldur Johannsson wrote:
>Þann 7.apríl 2008 skrifaði Pierre THIERRY <nowhere.man at levallois.eu.org>:
>-snip-
> >  I suspect that Lamport here has a bias, in that the only systems he
> >  knows, for they are mostly the only ones you can see currently, are ACL
> >  systems.

Be careful about the name.  We're talking about Butler Lampson,
not "Lamport" (Leslie?).  Leslie Lamport also works at Microsoft:

http://research.microsoft.com/users/lamport/

as does Butler Lampson:

http://research.microsoft.com/Lampson/

Butler Lampson was once considered an expert on capability systems.
I think the basis of that consideration was his work on the CalTSS system.
However, he abandoned capabilities fairly early on and it seems
to me has been a critic of the capability paradigm since that
time (middle 1970s?  Perhaps early 1980s?).

> >  ACL systems are to security policies what state machines are to
> >  algorithms: a very limited vocabulary. In this regard, Ocaps truly are a
> >  programming language to express security policies. I think it was a
> >  point discussed in MarkM's thesis, that Ocaps enable the creation of
> >  security abstractions.

Hmmm.  I'm not sure what you are getting at above.  It seems to me
that both capabilities and ACLs have rather limited "vocabularies".
I consider that to their credit in that it means that they are
relatively simple.

Capabilities: access tokens that can be communicated as parameters
               in requests/replies/messages.

ACLs: Principles and objects that can have Principles on their ACLs
       (added/deleted by a potentially distinct principle "owner" that
        does add a small amount of possible complexity to ACL systems)

> >  In most mainstream systems that I know of, fine grained security indeed
> >  is mostly impossible to manage. In the limited domain of those ACL
> >  systems that are currently used, maybe Lamport is totally right. It may
> >  take a lot of wizardry and hard efforts to get POLP right with them.

As I noted, I believe Lampson's argument is applicable to the
SELinux system which came out of the NSA that he also criticized
in his keynote presentation.  In my view it does take a fair
amount of "wizardry" to get mandatory SELinux policies right.
That some amount of that "wizardry" can be automated (e.g.
as Jonathan Shapiro pointed out) is to their credit, but it
seems to me that the base configuration, as Lampson notes,
is inevitably somewhat complex and must be established by
a person who understands that complexity (difficult) and
how it must be adjusted as conditions change (also difficult).

>I think reason why POLP is unworkable in ACL systems is that
>designation and authorization graphs are separate and, as everyone who
>handles databases
>probably know, keeping two interdependent datasets in sync is very hard.
>Were as in ocap system the two graphs are one and the same and
>therefore (innuently deducted) the over-all system is simpler (less
>complex).

I can see some truth to the above statement.  However, for me
the main issue is that with capability systems the authorization
mechanism is simple parameter passing - which already needs
to be in place to communicate designation information.  Perhaps
that's what you are saying above?  For me it isn't "just" that
capabilities can combine designation and authorization, but
also that they can do so with simple parameter passing that
already needs to be in place to specify designations.

>Regarding the "stopgap" or "bailing" side of security:
>As the phrack article "Smashing the stack for fun and profit" and
>numerous other articles on code injection demonstrate, it is mostly
>about Confusing deputies attacks.

I assume you mean "Confused Deputy" attacks.

>Antivirus, safe inputs and intrusion detection systems are about
>finding the unsafe data that confuse authority wielding programs to
>treat it as code where that behaviour of the deputy was not intended.

I agree, though I think you may be using the term "Confused Deputy"
more broadly than it is typically used on this list.  That's something
that I don't think was fully clarified in our recent flurry of
discussion about the "confused deputy" situations.

>With ocap based system such attack isnt so bad as it gives the cracker
>limited authority but with (aptly named) eggshell security you (as the
>sysop or sysowner) are pwned.

I'm not sure what that last word ("pwned") is intended as, but
its probably bad.  I agree.  I haven't heard that term "eggshell
security" in some time.  Thanks for reminding me of it.

>What is computer security about other than control of access to
>resources, data and other components of the system?

Generally that seems to be what its about.  The dominant ACL
model seems to take the position (from early Unix and Multics)
that programs run on behalf of users and therefore should
have all the access rights of the users they run on behalf of.
With that view the issue of control of access to resources
is naturally framed in terms of control of access to resources
by "principle"s ~= users ~= people - e.g. on ACLs.

Of course I take a position opposite to the above - arguing
that access control is properly handled at the process level
with capability tokens that can be communicated in requests,
and that people ~= users, the "who" of computer systems,
should properly exist at a higher level where they can
control which of their resources/objects (e.g. with a
"power box") they give to programs running in processes
(domains) on their behalf - e.g. with mechanisms like Horton.

My view is that the computer systems properly only trust
us people with as much access as we are authorized to
have by their policies.  I believe we people should
be empowered to likewise only trust programs running on
our behalf with authorities that we choose to grant them.

>Just my thoughts on this discussion.
>-Baldur Jóhannsson

Thanks for contributing!

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