[cap-talk] In Defense of Identities - really not

[Jed Donnelley]

At 01:35 PM 12/6/2006, Jonathan S. Shapiro wrote:
>On Wed, 2006-12-06 at 13:17 -0800, Jed at Webstart wrote:
> > Of course I argue that any permission to an object should convey the
> > permission to modify the object's ACL - exactly so as to delegate
> > that permission to another subject....
>
>This is exactly what you do *not* want. You want the *ability* to do
>this, but not the mandate to do this.

I ask again (sorry if I missed an earlier response), if the subject
with a permission isn't permitted to delegate it, who is?

>There is value (in the form of a
>barrier cost created by the need to proxy) in controlling delegation --

You refer to "controlling" delegation, but it seems to me you're
really referring to blocking delegation.  I imagine a modular programming
system where I can be called with a parameter, but I'm unable to
pass that parameter to another module to complete what I've been
asked to do.  I'm sure I must have the wrong picture.  Perhaps
you can flesh out how this is working work for me?

>and especially so in a shared system like OpenCM where user sessions are
>intentionally very short and there is no ability for users to introduce
>code (therefore no ability to proxy).

Let's see.  Users can't run programs and subjects can't delegate.
What can one do in this 'Open'CM?

> > If you deal with the
> > permission to modify an ACL in that way then I argue that you have
> > created object-capability semantics with an ACL implementation.
>
>Indeed, but why in the seven hells would anybody build all of that
>mechanism if all they wanted was capabilities? I don't understand why
>going through all that bother makes any sense.

It seemed a pretty natural fit in the DCCS:

http://www.webstart.com/jed/papers/DCCS/

At that time I didn't have nor want to deal with a cryptographic
infrastructure.  What alternatives were there?

> > >The original OpenCM design
> > >did not distinguish these write authority. The later version (which is
> > >finally getting cleaned up now) does.
> > >
> > >The directory example is going to force me to reconsider whether we
> > >handled the ACL issue well. I'm beginning to think that we may want to
> > >re-open it.
> >
> > Sigh!  Even flap in implementations?  Is it any wonder our systems don't
> > climb in market leadership?  I argue that if your ACL 
> implementation doesn't
> > supply object-capability semantics for delegation then your design does
> > indeed need to be re-opened!
>
>It doesn't. It won't. That's deliberate, and in the context of OpenCM it
>makes sense. MarkM went down this rathole with me years ago, and
>reluctantly concluded that the choices we made in OpenCM were better
>than capability semantics for this application.

OK.  I'll stay out of it until I know more about OpenCM.

>However, there are other constraints operating in the OpenCM case that
>may make it extremely unusual. It seems unlikely that it's a
>generalizable example, though it also seems like we should examine the
>proposition that it might be.

If you're talking about a system without actors (subjects - you say
no programming above) then I'm afraid that much of my reasoning about
delegation doesn't apply.  There's nothing to do delegation.  I can
see how object-capability semantics doesn't make sense in such a system.

However, every such system that I've seen is embedded in a larger
systems (language, OS, network) where there are actors (subjects/processes)
that can find themselves in very difficult straights if they are unable
to do delegation.  I find it difficult to imagine how the actors
dealing with permitted actions in OpenCM can develop effectively
modular systems.  It seems to me the focus of the access control
issues in OpenCM is there to deal with the very cross organizational
issues that object-capability semantics are best at - exactly because
there are no common identities.  Does OpenCM make up it's own identities?
Require it's own binding to these identities (authentication)?

Oh well.  I guess I better not go there.

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