[cap-talk] Users in object/capability systems (was: MLS gone bad, Lampson)
devbox at selnet.org
Wed Nov 22 20:00:51 CST 2006
On 21/11/2006, at 10.24, Jed at Webstart wrote:
>At 10:11 AM 11/18/2006, Valerio Bellizzomi wrote:
>>On 17/11/2006, at 16.54, Jed at Webstart wrote:
>> >Hmmm. The above seems a bit fuzzy to me. Isn't the binding to the
>> >UID done when you (the real you, the person) authenticate to the
>> >system? Sure, that authentication can go awry, but if it works
>> >then the binding to the UID can be fairly strongly assured.
>>Who tells to the machine that it is really me and not someone else using
>Nothing. This is of course a well known problem. I don't believe it
>substantially detracts from the basic identity paradigm.
I find more proper to talk about identities than talking about persons.
>> >>I think it all stands on the knowledge of the user intention, because
>> >>if there was a full body scanner to acknowledge that effectively you
>> >>the logging-in user, the system is not in a position to tell that it
>> >>your intention to access the system.
>> >I don't understand your use of the term "intention" in this
>> >To me the "intention" of the user doesn't really matter. I just want
>> >to know that the user is responsible for the actions that are
>> >logged as having been performed by the UID.
>>In this case we are not talking on the same wavelenght.
>>It is really easy to fool the machine to think that I am You (by
>>your credentials), so that what I do on the machine appears as Your
>I perhaps don't agree with "really easy". So much of today's IT
>infrastructure is based on the assumption that it isn't "really"
>easy to steal credentials, and I believe it's working reasonably,
>though of course not perfectly.
I meant that it is easy to fool the machine with current login mechanisms
(username/password), not that it is easy to steal credentials.
Of course there are organizational factors that come into play (like
"never write passwords on paper" etc..).
>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
>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
>> >Stolen credentials/authority is of course a well known problem that
>> >has many approaches to deal with. My primary concern in this
>> >discussion is how effective the systems are (acls vs. capabilities)
>> >assuming the authentication for initial authority is effective.
>> >See my most recent "Capabilities - the rub, an account" message
>> >for more details in this area.
>>We are not talking about the same thing. I thought your primary concern
>>was with revocation.
>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 know,
>the dominant breed) have with capability systems. Particularly after
>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
>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.
>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.
>If one wants to make available a capability infrastructure that can
>provide more personal accountability and auditing, how could it
>be done? I was just suggesting some mechanisms. Sure we
>know that one can always create a revocable capability equivalent
>to some other. I was suggesting a means for doing so with a
>mechanism that is tied into delegation so that only the person
>(identity - OK to your identity theft arguments) to whom the
>capability has been delegated can access it. I believe such a
>facility could provide for better auditing and finer grained
>accountability 'even' in an object/capability based system - contrary
>to what the acl people seem to believe.
>The above is, I believe, along the lines of the argument about revocation
>in the Capability Myths Demolished paper, but goes a bit further in
>what it provides.
>> >>My experience with capability based systems starts with EROS. I try
>> >>find my way...
>> >And? Does EROS work as above or otherwise?
>>It isn't yet clear to me how a running Coyotos system will work.
>The above is all pretty simple DVH sort of capability stuff. I believe
>it could even be supported in the network capabilities as data world,
>except that there needs to be some sort of escrow mechanism or
>otherwise to insure that the identity (e.g. process) that creates the
>new delegated capability can't itself access it.
>> >There is some "superuser" that has control of the system. That
>> >can make the system look like anything they wish.
>>Yes, but also the "system architect" can make the system look like
>>anything they wish.
>>The system architect is a "super-superuser".
>>So I think that if we talk about a "superuser", we have to define how
>>we trust the System Architect, the Installer, and the Operator,
>>our talk takes a dead-end way.
>Fine. No problem.
>> >Can you explain what an "account capability" is? That is, what
>> >operations are available on it? What sorts of limitations are there
>> >on communicating such capabilities? Such a capability sounds
>> >suspiciously like an "identity" capability and of course there
>> >are serious problems in that area.
>>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 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
>>I said it that I see serious problems, we don't understand each other
>>a problem of terminology, but I think also our concerns are different.
>>My effort to start a capability definitions dictionary has not
>>enought consensus as to motivate me to continue the effort, if you are
>>interested please let me know.
>Are you considering a dictionary of object/capability related terms
>(e.g. revoke, delegate, invoke) or something more like a taxonomy
>of capability types (e.g. file, directory, process, account)?
Both sound good, I would keep them separate, they could also be
More information about the cap-talk