[cap-talk] MLS gone bad - now capabilities? (was: NCSC TCSEC) Lampson trashes POLP

Valerio Bellizzomi devbox at selnet.org
Thu Nov 16 19:03:55 CST 2006


On 15/11/2006, at 17.33, Jed at Webstart wrote:

>At 03:08 AM 11/10/2006, Bill Tulloh wrote:
>>On 11/9/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
>> > At 05:01 AM 11/5/2006, Bill Tulloh wrote:

(snip)

> From my perspective his writing in recent years has been pretty much
>conservative apple pie and motherhood sorts of stuff arguing that what
>we have has worked well enough and will continue to do so with perhaps
>just a bit more diligence (not surprising for somebody working for
>Microsoft I guess).  For example, in the talk at the above he says:
>
>"The danger is small, so it's OK to buy features instead of security.
>Security is expensive.  Security is a pain."
>
>However, more particularly to our capability/POLA cause is this quote:
>from Butler 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 no to 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."
>
>I believe Fred Schneider's concerns (below) are similar:
>
>>and Fred Schneider argues that while it might be useful as an abstract
>>goal, it is not implementable.
>>http://www.cs.cornell.edu/fbs/publications/leastPrivNeedham.pdf
>
>The problem with the above (Lampson and Schneider) I believe is
ignorance.
>Neither have ever seen an object/capability paradigm through to a
complete
>system.  They imagine POLA implemented by third party administrators
>that must manage ACLs to the least privilege principle.  They imagine
>something along the lines of administratively controlled Mandatory Access
>Control as per the MLS schemes that have worked out so disastrously
>in the military (about that we agree).

Here we agree again, I think they see POLA/POLP managed by hand, but this
is plain wrong since there should be administration tools (P.AdminTools)
that are expressly designed for that task.
And if at large it is an issue of policy management, P.PolicyRigor says it
all:

"The TOE shall not allege to enforce a security policy unless (a) it can
be shown that there exists some means by which the policy is in principle
enforceable given the protection mechanisms implemented in the TOE, and
(b) the TOE in fact implements some embodiment that performs such
enforcement using these mechanisms."

So I think that what Lampson says is plain against POLA, but I think that
it can be shown that he was wrong on this argument.

>
>What I believe they don't understand and/or fail to appreciate is that
>POLA implemented with object/capabilities is almost entirely just
>good object programming - parameter passing rather than using
>"global" state sharing (authenticated through identities).

We agree again, this is exactly what has been started with structured
programming, parameter passing and local variables instead of global
variables, thus more control over state change. I started learning it with
Pascal and then with C, it was really "another world" beyond the spaghetti
programs of BASIC, then BASIC started going the way of Pascal by adding
gosub/return statements so that programmers could avoid the depleted
"goto" and write more structured BASIC programs, but it never reached the
same level of structuration of Pascal.
Somehow Pascal retained a sort of escape from the structuration with
"labels" that could be used as "goto", but sincerely I have used them very
rarely, and in my view they were a violation of the structure of a
program. It really is an issue of "forma mentis".


>
>Lampson certainly refers to and suggests using delegation extensively,
>e.g. when he discusses the "speaks for" relation (e.g. page 15 of the
>charts:  http://www.usenix.org/events/sec05/tech/lampson.pdf ).
>
>If well respected people like Lampson are giving talks, writing, etc.
>and saying, "I say absolutely no to fine grain protection.  Everything
>should be as course grain as possible" then what hope is there for
>advancement along the POLA lines?  Wait for Lampson to retire into
>obscurity, confront him and any who think like he does directly, or
>try to work around naysayers like Lampson.
>
>Generally I prefer direct confrontation and clearing the air.
>
>> > BUT (and its a big BUT):
>> > 1.  How do you manage access control in an object/capability
>> > system (see my recent "Capabilities - the rub" message) -
>> > audit, remove, see, etc. and
>>
>>I'm probably the least competent person on this list to tell you how
>>to build such a system, but I do think your "rub" is on to something.
>>Identity-based systems are modeled after people "owning" computational
>>objects, like files. The focus is on user as principal. This is a
>>legitimate pattern that ACL systems attempt to address.
>>
>>What I take as the capability response to this, mainly from reading
>>this list, is two things.
>>
>>1. Programs are people too.
>>
>>Systems that base access control decisions on the identity of the user
>>only give you the illusion of control, because they make the
>>unwarranted assumption that the executing code faithfully pursues the
>>user's interest. Capability-based systems model programs as pursuing
>>their own separate interests, programs as principals. To quote Norm
>>Hardy:

I say it again in the hope that I write it clear and understandable: Each
user is represented in a system by programs, so I tend to think in terms
of "programs as principals", since a system only understands code, the
system does not knows what a user is, the fact that ACL systems give
identity-based access is only an artifact of implementation, as I see it,
in an object/capability system, each user is himself a capability, and the
system code only understands capabilities.
If I am wrong please correct me.

(snip)


val



More information about the cap-talk mailing list