[cap-talk] Users in object/capability systems (was: MLS gone bad, Lampson)

Valerio Bellizzomi devbox at selnet.org
Sun Nov 26 19:46:37 CST 2006

On 26/11/2006, at 12.08, Jed at Webstart wrote:

>At 06:00 PM 11/22/2006, Valerio Bellizzomi wrote:
>>On 21/11/2006, at 10.24, Jed at Webstart wrote:
>> >Regardless of that, however, I do believe the paradigm of separating
>> >access control into an authentication part (use some form of
>> >to identify a person) and then authorization (access control -
>> >what that person and the programs acting on his/her behalf are
>> >to do contingent on their identity) is a legitimate paradigm.  I agree
>> >there doesn't seem to be any way to effectively achieve POLA with it,
>> >but I still argue that it is a legitimate approach that's been used to
>> >relatively good effect for some 50 years now.
>>Ok, but it is a legitimate approach that led to the current situation,
>>notably vulnerability to viruses etc..
>>As MarcS said, I could be the grandchildren that laughs at the silliness
>>of it.
>I don't agree that the separation of authentication (of a person at
>from authorization is what causes the lack of POLA that creates such
>serious vulnerability from viruses.  Even in an object/capability system
>there is a need to authenticate people who connect to a system - even
>if programs don't run with all a person's permissions.

The user shell would have to run under POLA too.
OTOH, the authentication of user could be executed in two phases:
1. login setup phase = enter username+password,
2. login commit phase = enter "control code".
The commit phase could be subject to timeout.
This is inline with current model of atomic action kernel, "setup phase"
and "action phase".
It isn't a panacea but it is harder to steal two authentication codes.

>> >At the big picture level my focus in this thread is to address some of
>> >issues that acl people (e.g. Lampson, the TCSEC folks, etc. - you
>> >the dominant breed) have with capability systems.  Particularly after
>> >recently reading both Lampson and the TCSEC folks absolutely trash
>> >capability systems I think this is relevant to moving the
>> >paradigm (and with it POLA) forward.
>>I don't think trashing each other's paradigm is a method that advances
>>further, I believe it is more savvy to take the best of the two worlds
>>integrate them.
>If I understand your meaning I believe that's what I'm trying to do.  We
>must recognize that communicating conspirators (proxying) is always
>possible.  What we want is mechanisms that recognize this truth and
>provide us as much auditing/control as we can achieve given that
>permissions can always be communicated (where communication
>exists of course).  That's where I'm trying to go in the "Re: [cap-talk]
>Capabilities - the rub, an account, base functionality" thread.

Of course, if I have access to a file and you don't, I would just email it
to you or print it and hand it to you.
Stopping communicating conspirators would require a military-like
organizational model at human level, if it suffice.
One thing that could be avoided inside the software to a certain extent,
is the possibility of "wall-banging"..

>> >What came next was derived from the above high level goal.  Namely I
>> >was hoping to show that object/capability systems can provide an
>> >equivalent level of auditing (specifically for delegation, but
>> >and fine grained and person identified access control.
>>Right, I think it could actually provide *better* level of auditing
>>it is finer-grained.
>and of course can achieve POLA access control at the process
>(active object) level - which at least in this community we
>believe is valuable (contrast 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 find this Lampson's argument weak, not only we can keep track of
dependencies with automated tools, but it isn't told that it is more
complicated, rather I would say that fine grain is much more configurable
than the rwx ugo stuff.
The empirical evidence is changing now, since the software is more

>).  I believe we need to convince people like Lampson that communicating
>just POLA permissions need not be very complex and may in fact
>amount mostly to just good object oriented program/interface design.
>Most of it is not even visible at the level of an administrator or even
>as a user.  It happens largely automatically - though again remember
>that we're talking about the "discretionary" access controls that are
>possible in the fact of communicating conspirators.
>> >One of the problems that concern the acl people (pardon me for
>> >lumping and simplifying that group, but there you go) is that
>> >capabilities can be communicated freely (wherever data communication
>> >is possible) with no tie to personal responsibility.
>> >
>> >Yes, yes, we know that such delegation can happen in any case
>> >with conspiring communicators.  Let's not repeat that issue.
>>There come into play the "account capability", used for accounting, of
>>Imagine that each record of a capability transfer log is tagged with the
>>account capability of the identity doing the transfer.
>Sigh.  I believe there is contention in the above topic.  I think 
>I've described
>a mechanism to provide auditing that is about all that can be achieved in
>the "Re: [cap-talk] Capabilities - the rub, an account, base
>thread.  I don't believe "account capabilities" are needed for that 
>I hope we can at least postpone any such discussion - where I believe
>there is more than one way to do it.

Ok, postponed.

>> >>To me the "account capability" in an object/capability system is the
>> >>equivalent of the UID in an ACL system.
>> >
>> >Hmmm.  UIDs in ACL systems are used for access control.  I hope
>> >you aren't suggesting that an "account capability" be used for a
>> >access control purpose.  I believe that road leads to nonsense.
>>An "account capability" could be used for accounting, notably process
>>accounting tied to an identity (see above: transfer log).
>I at least am definitely NOT suggesting that an "account capability"
>be used for access control.  That notion makes no sense to me.
>> >I find it amusing that in our NLTSS system we actually did have an
>> >"account capability".   It was a little like a UID, but for accounting
>> >(charging) purposes and not for access control.  Still there were some
>> >awkward aspects with it in that wherever it was communicated
>> >could of course make similar charges to that "account".  We had
>> >mechanisms for subdividing "accounts" to deal with this issue, but
>> >they weren't entirely satisfactory in my opinion.  One wants to be
>> >able to delegate permission but not identity.
>>This "account capability" would have to be closely held, similarly to a
>>kernel capability.
>"kernel capability".  Even such an "account capability" is 'only' as
>as a user's "money" is on a system.  Still, I think we have more
>issues to deal with before we get there.  It will be interesting to me to
>if we get into this accounting topic on Friday at HP when we talk face to

I believe I would not be allowed to participate such a meeting since I'm
not Ph.D and I would not add value to the meeting :-)
Anyway, unfortunately right now I cannot attend such meetings unless they
are in Rome, Italy.
Oh, I'm not very fluent in spoken english, at the moment I can only write
in english and understand few english speech.


More information about the cap-talk mailing list