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

Valerio Bellizzomi 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:
>>
>><snip>
>> >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
properly
>> >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
>>my credentials?
>
>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
>>even
>> >>if there was a full body scanner to acknowledge that effectively you
>are
>> >>the logging-in user, the system is not in a position to tell that it
>was
>> >>your intention to access the system.
>> >
>> >I don't understand your use of the term "intention" in this
discussion.
>> >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
stealing
>>your credentials), so that what I do on the machine appears as Your
>>responsibility.
>
>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
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.

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


>
>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
course.
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.
>
>><snip>
>> >>My experience with capability based systems starts with EROS. I try
to
>> >>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.
>
>><snip>
>> >There is some "superuser" that has control of the system.   That
person
>> >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
much
>>we trust the System Architect, the Installer, and the Operator,
otherwise
>>our talk takes a dead-end way.
>
>Fine.  No problem.
>
>><snip>
>> >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
kernel capability.

>
>>I said it that I see serious problems, we don't understand each other
for
>>a problem of terminology, but I think also our concerns are different.
>>My effort to start a capability definitions dictionary has not
encountered
>>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
cross-referenced.

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





More information about the cap-talk mailing list