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

Valerio Bellizzomi devbox at selnet.org
Tue Nov 28 15:11:11 CST 2006

On 27/11/2006, at 14.59, Jed at Webstart wrote:

>At 05:46 PM 11/26/2006, Valerio Bellizzomi wrote:
>>On 26/11/2006, at 12.08, Jed at Webstart wrote:
>> >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
>> >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.
>POLA perhaps, but for a user shell POLA must necessarily provide
>all the access the user has so that any such access that is appropriate
>(POLA) can be given to programs running on the user's behalf.  I believe
>this means that the user's "shell" (perhaps others prefer the term
>"power box") must have all the user's authority.

Yes, but not all the time the user is logged in.
Example: if a user leaves the workstation and the session becomes idle
(with no programs running), and a screen saver is fired up, fewer
authority is needed in this time.

>>OTOH, the authentication of user could be executed in two phases:
>>1. login setup phase = enter username+password,
>Of course there are many ways to do authentication - namely
>to bind a person to a communication stream.  Username/password
>is of course one (ssh key exchange, biometrics, etc., etc.)
>>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.
>I'm sorry, but you lost me in the above.  Are you suggesting augmenting
>any given authentication scheme (e.g. biometrics) with another
>(e.g. ssh key exchange) for better tie-in on authentication?

Basically I suggest using two passwords, but this isn't the real issue
here. I was suggesting to make the login process strictly tied to the
kernel model of operation.

>> >If I understand your meaning I believe that's what I'm trying to do.
>> >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:
>> >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
>>to you or print it and hand it to you.
>This is something that MarcS has mentioned a number of times.  I
>think it's important to note that sharing a copy of the data in a
>file is not the same as sharing access to the file.  With shared read
>access new changes are visible to whoever has that read access.
>With shared write access of course such permission allows
>modifying a file into the future - long after its contents have
>changed (e.g. new board secrets have been added).

If you can share, you don't need to do proxying.

>I realize I'm stating the obvious, but the fact that this sort of shared
>paradigm goes far beyond what one can achieve with copying I think is
>important.  Many years ago (1970s) at LLNL we had a central storage
>system that worked on the object/capability principle.  Every user had
>the ability to:
>1.  Create files and directories out of whole cloth (account).
>2.  The ability to share any capability with either:
>      a.  One other user at a time (the other user saw the capability
>"magically" show up under some name in their receive directory) or
>      b.  Share a capability with the world - basically making it so
>that it can be "taken" from what appears as a globally shared directory
>of all users by username.
>With the above scheme I can create a new project directory that I
>might call BOD (Board Of Directors).  I can then give it out to each
>of the directors.  Each director can then look in:
>and find this directory with whatever sort of shared access I provided.
>This approach was great for allowing users to make up what amount to
>new groups on the fly.  However, this mechanism was subject to the
>criticism that the TCSEC folks leveled at "traditional" capability
>Namely there is no auditing with it.  Once I give out those capabilities
>everyone that I give them to has the exact same capability with the
>same permissions and the same auditing trail.  That system did not
>have the feature I suggested recently of making every delegated
>capability different, with a delegation trail and independently
>and communicated in such a way that the sender cannot access the
>delegated capability for proper responsibility tracking.
>I believe adopting such means to track delegations would go a
>substantial way toward addressing some of the concerns of the
>TCSEC folks (though not Lampson - whose concern seems to be
>about complexity induced by POLA.  I believe he wrongly assumes
>that POLA can't be simple and natural - like parameter passing).
>I also believe such additional tracking needn't itself introduce
>onerous administrative complexity (e.g. the recent Brinkmann

I agree.

>>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"..
>Hmmm.  Of course an easy way to stop communicating conspirators
>is to stop the conspirators from communicating.  Stopping communication
>by "wall banging" in shared resource systems is a hard problem.  My
>approach generally is to not utilize shared resource where such wall
>banging might be a concern.  Beyond such "covert channels" if
>communication is only enabled in a system by possession of a capability
>and capabilities are distributed according to POLA, then I think you're
>doing about as well as you can.  You're doing so hugely better than
>anything we have today that I think the delta can be left to our

Wall-banging is one of the problems Coyotos and caps in general are trying
to solve. If you read carefully the ASPOS/PP, it already takes some
countermeasures to wall-banging.

>> >> >What came next was derived from the above high level goal.  Namely
>> >> >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
>> >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
>> >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
>> >absolutely no to fine grain protection.  Everything should be as
>> >grain as possible because otherwise you won't be able to administer
>> >That's a very unpopular position with most people.  I think there's a
>> >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
>>than the rwx ugo stuff.
>>The empirical evidence is changing now, since the software is more
>Hmmm.  I think the issue Lampson (who's quite well known and generally
>well respected I should mention) is addressing is the complexity that
>arises out of requiring administrators to manage ACLs - whether the
>owner of an object protected by an ACL or an administrator of a system.
>In either case I think you run into the problem of "fatal deceit" that
>MarcS mentioned.

If I wanted to follow his suggestion of "Everything should be as course
grain as possible because otherwise you won't be able to administer it."
then I wouldn't ever use the rwx ugo stuff, but just plain DOS read-only


More information about the cap-talk mailing list