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

Jed at Webstart donnelley1 at webstart.com
Sun Nov 26 14:08:05 CST 2006

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 credentials
> >to identify a person) and then authorization (access control - determine
> >what that person and the programs acting on his/her behalf are permitted
> >to do contingent on their identity) is a legitimate paradigm.  I agree that
> >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 least)
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.

> >At the big picture level my focus in this thread is to address some of the
> >issues that acl people (e.g. Lampson, the TCSEC folks, etc. - you know,
> >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 object/capability
> >paradigm (and with it POLA) forward.
>I don't think trashing each other's paradigm is a method that advances us
>further, I believe it is more savvy to take the best of the two worlds and
>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.

> >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 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 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.

> >>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 similar
> >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 sensitive
as a user's "money" is on a system.  Still, I think we have more important
issues to deal with before we get there.  It will be interesting to me to see
if we get into this accounting topic on Friday at HP when we talk face to

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

More information about the cap-talk mailing list