[cap-talk] - Bellizzomi - Users in object/capability systems (was: MLS gone bad, Lampson)
Jed at Webstart
donnelley1 at webstart.com
Mon Nov 27 16:59:56 CST 2006
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 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.
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.
>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?
> >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.
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).
I realize I'm stating the obvious, but the fact that this sort of shared access
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 systems.
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 revocable,
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
>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 posterity.
> >> >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 generally)
> >> >and fine grained and person identified access control.
> >>Right, I think it could actually provide *better* level of auditing since
> >>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
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
> >>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 functionality"
> >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.
More information about the cap-talk