[cap-talk] the value of non-delegatable authority?

[Jed Donnelley]

At 07:08 PM 1/11/2008, Toby Murray wrote:
>On Fri, 2008-01-11 at 11:48 -0800, Jed Donnelley wrote:
> > On 12/22/2007 12:15 AM, Mark Miller wrote:
> >
> > > Jed, they <Toby and Duncan in their paper:
> > "Non-Delegatable Authorities in Capability Systems"
> > http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/NDA.pdf >
> > > are not doing "non-delegatable objects" or permissions. They
> > > are doing non-delegatable *authority*.
> >
> > As this discussion seems to have died, I think I should at
> > least correct one thing I said with regard to the above.
> > Namely in:
>
>Sorry Jed. I've been meaning to get on this discussion but have been
>distracted lately.

Happens.  Thanks for taking time to respond.  I think this is an
important issue for the object capability model, so I would like
get it discussed.

>For the record (although my views are by no means fixed here) I see the
>fundamental contribution of the "Non-Delegatable Authorities in
>Capability Systems" (NDAICS) paper as showing that one can, in
>fact, /express/ non-delegatability in the object-capability model. It is
>fundamentally arguing about what can be expressed and I think on this
>point it is solid.

<minor>
The above is a relatively minor point for me, but I would like
to ask one question in this regard.  In the paper you describe
the Authority by Method Return mechanism that you build on to
implement the non-delegatable authority mechanism.  You note
that in many object-capability systems the return authority
isn't represented as a capability (e.g. E, W7, and the Annex
Capability System) and consequently isn't delegatable through
normal capability communication, while in some object-capability
systems the authority to return is represented as with all other
authorities as a capability (e.g. EROS and RATS - what about KeyKOS?)
and can be delegated.  Doesn't this suggest that the non-delegatable
authority approach that you are using is at least dependent on
the particular sort of object-capability system?  That is, in
systems where all authorities are represented by capabilities
(which I regard as a "good" thing - what's good for one
authority seems to me good for all) the non-delegatable authority
mechanism that you describe can't be implemented.  In other
systems (those with an authority to return that isn't represented
as a communicable capability) you can use this "feature" to
implement a non-delegatable authority.

To state my position most strongly, I see the non-delegatable
authority mechanism that you describe as a "hack" on an
obscure and unfortunate inadequacy in some object-capability
implementations.  I'd be interested to hear your or others
present arguments that representing the return authority as
a communicable capability is a bad idea for the general
object-capability model - and thus that building the
non-delegatable authority mechanism as you have is more
of an appropriate "rule" for object-capability systems
rather than an unfortunate "exception" as I see it.

Of course if we could decide that non-delegatable authority
is a good that needs to be supported, then we could build
it into the model (e.g. as they did in DEMOS with the
"pass once" capability).  I don't think this would be
a good thing, but that is what I view this discussion
as being about.  With such a mechanism delegating
non-delegatable authority would be simple and easy as
it would be directly supported by the model.
</minor>

>The paper also tries to lay out the arguments in favour of
>non-delegatable authority in order to motivate why one might want to
>express non-delegatability in the first place. On this second point, the
>paper may be less solid; although I make no claims one way or the other.

Focus:

This is the area where I hope we can focus our discussion.
I believe such arguments feed into what I refer to as the
"loose capabilities" fear.  I also agree that "people seem
inherently drawn to the idea of non-delegatability
of permissions" as you note later.  In fact what such
people hope to achieve (I hope we will agree) is non-delegatable
authority - which is the stronger claim in your paper.

I believe that if this fear of delegation through
capability enabled communication channels is accepted
as justified then we may as well pack up the object
capability model and go home.  The ability to
delegate through existing capabilities is a fundamental
part of the model.  If people's intuitive fears of
such delegations are justified, then the object capability
model is repudiated.

I believe this is a case where what people intuitively
feel drawn to is misguided.  As I believe you have clearly
described, there are two aspects to the consideration of
efforts toward non-delegatable authority:

1.  The cost.  As far as this goes, I go further than your
statement: 'I agree that non-delegatability is potentially
harmful because it breaks the assumptions of programmers
and makes it difficult to impossible to create the sort of
"networks of subcontracting" for which the OO paradigm is
so adept.'  I argue that non-delegatability *is* harmful
for effective access control and thus security both in
the area of programming - where, as you say, it breaks
what I refer to as the decomposability of object oriented
programming (forcing one to break the model by proxying
to subcontract) - and in the area of interactions between
people, e.g. at the level of network communication of
authority that I feel is so important, but also even
delegation between people without computers where, if it
could really be supported, it would block use of administrative
assistants, cabinet members, effective staff, and the like.

and

2.  Value.  Here you say "It might be the case that while
non-delegatability is useful between humans..." seeming to
assume that it's clear that non-delegatability is clearly
of value between people.  I dispute this point and feel that
perhaps this might be a good area to focus some discussion.

I believe that even in human institutions the ability to
delegate authority is vital for making such institutions
work.  I wonder if there may be a bit of confusion between
authority (that is the ability to take or allow an action)
vs. responsibility (e.g. ultimate responsibility - namely
where the buck stops) for an action?

I'm not sure how we can answer this question.  I know
I have been on the receiving end of authority delegation
(e.g. final decisions for salary actions, purchasing
decisions, etc.).  While there may have been a formally
responsible person (with an "authority"?), the actual
authority was delegated and even the signature mechanism
was handled by an administrative assistant.  I believe such
mechanisms work all the way up and down typical authority
hierarchies in most (all?) human organizations.

Do others disagree?  I'll be interested to hear of
structures where others have experienced authorities
in human organizations which may argue for the
practical importance of non-delegatability in human
organizations.

I believe that in human institutions just, as in
computing systems, the point that David Wagner most
recently stated, "Don't prohibit what you can't
prevent" applies up and down the line.  Any imagination
of value for non-delegatability is illusory IMHO. I
believe such illusions may be most easily harbored
by those who have never had such "non-delegatable"
authority actually delegated to them.

 From my experience these same properties (below) of
efforts at non-delegatability apply in both human
institutions and in information systems:

1.  Costs: Efforts at non-delegatability (despite being
intuitively appealing, as I acknowledge) inevitably result
in high costs, particularly when, to make things work
(e.g. another level of decomposition, or as you refer
to it "sub contracting"), such efforts must be circumvented

and

2.  Value: No real value - "Don't prohibit what you
can't prevent."

I was particularly interested in the sections in your
paper where you argue for the value of a non-delegatable
authority mechanism.  As you correctly note in your
section 1.2 ("The Value of Non-Delegatable Authority"),
if Alice has a non-delegatable authority then she is
unable to share "exactly" that authority with Bob.
You argue that forcing Alice to proxy if she wishes
to delegate as much as she can of this authority
to Bob is a positive value.

I ask - value for who?  It certainly isn't a value
for Alice as Alice has the opportunity to proxy in
any case.  Granting Alice only a non-delegatable
authority gives Alice fewer options and so doesn't
seem to provide a value for Alice.

It would seem then that the additional value (if any)
can only accrue to some unnamed "Aaron" who had
the authority to begin with, needed to share it
with Alice, and chose to do so as a non-delegatable
authority because he presumably didn't fully trust
Alice.  For example, he thought Alice might have
a bug which might later be corrected as you suggest.
<This ignores the possible value to Alice of
not trusting herself.  In this case she would
presumably proxy all delegated authority on
the chance that any might be inappropriately
delegated.  I hope this isn't considered an
important case, but we can take it up later
if it is>

If you are to argue for the value of delegating
with a non-delegatable authority from Aaron to
Alice then it seems to me you need to consider
the options available to Aaron.  Aaron has at
least these three options that seem relevant
to me:

a.  Communicate the authority directly as a
capability (reference),

b.  Communicate the authority in the non-delegatable
manner that you describe, but also

c.  Communicate the authority through any sort
of a policy engine such as a simple revokable
capability, a more thorough membrane, an
identity based delegation tracking mechanism
like Horton, or any other possible policy engine
(e.g. indirect through a service that can
accept any sort of a policy module upload).

Since we assume that Aaron doesn't fully trust
Alice, it seems reasonable to exclude #a.
Between #b and #c which seems preferable?

This is a point at which I think it worthwhile
to examine what seems to me to be a missing element
from the discussion in your paper - namely, what
is the relationship between Aaron and Alice?
On one extreme Alice could be a sub part of
Aaron (e.g. an object within a single code
system).  This case seems to reduce to essentially
the case I mentioned above - namely that of Aaron
really not trusting himself.  I won't consider it
further here.

At the other extreme is the case where Alice
is a completely independent module - e.g. somewhere
on the network.  In that case when considering your
concern about a possible software fault in the
Alice code that can be exploited by Bob, mightn't
it be that Aaron could become aware of such an
exploit without being able to correct the code
fault in Alice?  In that situation #c would solve
the problem while #b would not.  It seems that
#c has more value in this case - at least for
protection (access control).

<obscure: potential value>
One situation where I can see some value in
the non-delegatable authority mechanism that I
can't see how to improve on is the case where
there is a program fault in Alice (as you
suggest) that can be corrected.  In that case
either #b or #c can protect from invalid
use of the authority when the fault is discovered,
but it seems to me that #b provides a less
costly correction.  Namely with #b correcting
the code (which must be done in any case) by
itself suffices.  With #c the authority must
be revoked through the indirection and then
it must be reissued somehow to Alice and
potentially wherever Alice delegated it.

I find it interesting that something like the
above was the original example that led me to
consider a mechanism like Horton.  Namely with
an identity based access control mechanism like
Horton, authority can be withdrawn or reinstated
on an identity basis through the Horton indirection
without needing to reinstate capabilities.
However, that approach doesn't help in this case
because we have no way to distinguish between
the authority granted to Alice as a capability
(assumed delegatable) and any authority that
Alice may have inappropriately redelegated.

I admit that I know of no way to obtain the
ease of correction that a code fix achieves
for an authority that was inappropriately
re delegated by proxy.  To obtain such a value
it seems to me that all delegation would have
to be done by proxy (e.g. as Alan indicated
was done with Client Utility as I recall?).
I hope this isn't considered necessary, but
I see no alternative if it is.

This line of reasoning has gotten rather far
afield.  I should note that ACL based access
control is no better with regard to this
particular problem.
</obscure: potential value>

Generally I believe that your paper underrates the
cost of non-delegatability and overrates the value.
If these merits are accepted then I believe the
object capability model is in serious trouble.

I believe the next step for the object capability
model is to provide human and computer interfaces
to delegate object references on the Internet
for use by programs, systems, and people.  An
identity labeling mechanism like Horton can
provide some comfort in this area - as long as
systems provide appropriate labeling of object
references by identity when delegation happens
(e.g. when communicating person to person),
then access by identity can be monitored and
managed (e.g. list/log access by identity and
revoke access by identity if desired).  However,
if the base authority to delegate through
capability enabled communication paths is
questioned, then there will be legitimate
reason to question the whole approach.  I
believe such questioning of the basic object
capability paradigm is misguided.  Certainly
compared to the unmitigated disaster that
we now have for network access control,
object capabilities seem to me preferable
to existing alternatives and also to object
capabilities with non-delegatable authority.

<One more minor technical point:>
I'll mention again here the issue that I
noted previously - namely that of capabilities
that are obtained through your non-delegatable
authority.  Aren't any capabilities delivered
through a non-delegatable authority themselves
delegatable?  Isn't this a problem with the
implementation for non-delegatable authority?
This is equivalent to the difference between
a simple revocable capability and a membraned
capability.  I don't believe this issue is
addressed in the paper by Toby and Duncan.
Shouldn't it be?  This is also not my focus
in this discussion, but I would like to
understand what is going on with their
non-delegatable authority in regard to what
might be considered indirect delegation
(communication of object references).
</One more minor technical point:>

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