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

Jed at Webstart donnelley1 at webstart.com
Tue Nov 21 12:24:26 CST 2006


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

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.

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

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.

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.

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.

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.

>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)?

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




More information about the cap-talk mailing list