[cap-talk] Toby's Confused deputy statement (was: Re: Confused deputies in hybrid systems)

Fri Feb 8 16:07:05 EST 2008

On 2/7/2008 7:29 AM, Jonathan S. Shapiro wrote:
> On Wed, 2008-02-06 at 11:43 -0800, Jed Donnelley wrote:
>> On 2/6/2008 1:03 AM, Toby Murray wrote:
...
> Challenge: please try to state what *you* mean by "adding a capability"
> and its impact on authority. Try it first using reasonably precise
> English, and then try to formalize it. I suspect you will find that the
> notion you are trying to capture proves to be very squirmy indeed.

Whew.  This seems to be becoming a seriously conflicting set of
views.  I started to wonder during the course of this message if
this conflict might be resulting from your focus on the
operation of the deputy (its programming) in terms of whether
or not it can be confused vs. my focus on the environment
of the deputy in terms on whether - even if it's coding were
optimal - it has any possibility of clarifying just what
authority it received from its client.

To me the essence of the "Confused Deputy" problem is
in the environment, not in the code of the deputy.
I believe this goes all the way back to Norm's initial
formulation, e.g. from:

http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html

______
The compiler serves two masters and carries some authority
from each to perform its respective duties. It has no way
to keep them apart. When it produces statistics it intends
to use the authority granted by its home files license.
When it produces its debugging output it intends to use
authority from its invoker. The compiler had no way of
expressing these intents!
______

That said, let me address your challenge and see if I
can provide any additional clarity:

What I mean by "adding a capability" is simply adding
a capability token to a c-list.  Before the capability is
added the subject is able to perform any sort of invocations
on the other capabilities in its c-list, passing any to any
others, but it can't invoke or pass the to be "added"
capability.  The subject's "authority" is whatever is
available through the "emergent" properties of the
servers that it has available under those circumstances.

After the capability is added the subject can perform
invocations on all it's previous capabilities as well
as the newly added capability, including passing any
of the original capabilities and the new one to any
now in the list.  The subject's new "authority" is whatever
is now available through the "emergent" properties of the
servers that it has available under these new circumstances.

The addition in principle increased the authority of
the subject.  How of course depends on the nature of
all the capabilities, the operations available on them
and how the servers respond to requests, including those
with multiple capabilities.  This comparison of the situation
without the capability to the situation with the added
capability seems quite clear to me.

When you say, "try to formalize it", perhaps you can
explain what you mean or give an example.  The above seems
adequately "formal" to me.

>> In the interest of simplicity can we try the modification of
>> Toby's original (simple) statement that I suggest in:
>>
>> http://www.eros-os.org/pipermail/cap-talk/2008-February/009831.html
>>
>> Namely:
>> __________
>> In any case in which a service may get more authority than its client
>> from a capability, the service is potentially confusable by that
>> capability sent from the client.
>> __________
> 
> For reasons that I have already addressed -- and that Toby has agreed
> with elsewhere -- this statement is devoid of content unless we are
> prepared to formally analyze the program obeyed by the service. In the
> absence of such analysis, the service is presumptively a maximal
> conspirator, and the client and the service therefore have identical
> authority throughout the scenario.

I'm not sure where the confusion lies, but one thing I
believe is that whether or not the opportunity for "confusion"
exists, it does so independently of the program in the server.
That program can be maximally conspiratory or it can do nothing
at all, and the potential for confusion is the same.  That
potential depends on the environment of the program receiving
the capability, not on its operation.  As Norm says, it is
serving two masters, its client and itself (with different
authority) and may wish to only act with the client's authority
in certain circumstances (e.g. in his case when writing
the compiled output).  The question is whether or not the
deputy has the necessary information to tell.  That depends
on the nature of its environment.

I'm not too hopeful of adding clarity with another example,
but it seems so clear to me that I'll give it a try.

Let's take an example like Bill Frantz's recent YURL
challenge where we assume:

1.  A base Horton implementation where we know the
delegation path of every YURL and disallow access if
anybody (by ID) on the delegation path is not permitted
access to the sensitive information, and

2.  The server acts (unwisely) UNlike a normal capability
server in that it looks at the network address that any
request on the YURL comes from.  If the request comes from
the VPN service, then it is not allowed.  If it comes from
anyplace else (presumed to be originating inside the
firewall) then it is allowed.

In this case consider a simple service inside the
firewall that retrieves information on behalf of a
client.  I send it a YURL and ask, "Please do an
http get on this YURL for me and return me the
results".

Such a client is, perhaps unknowingly, in a seriously
difficult "confused deputy" environment.  In general
it has no idea what sorts of restrictions other servers
may place on access to their resources (accessed through
YURLs) based on the requesting IP address.  It gets a
request and just carries it out.

In this case somebody outside the firewall can easily
access the sensitive data simply by making its
request for the data through this forwarding (proxy
if you like) service.  I'm sure I need not note
that such services can of course be very much
more complex and seem entirely reasonable on
first examination.

My main point is that the nature of a "Confused
Deputy" situation is the environment that the
deputy finds itself in.  If that environment
is such that adding a capability token to its
environment will add more authority than by adding
that same capability to the client's environment,
then the deputy is in a situation where it can be
'confused' when receiving that capability from
the client.  While it may wish to only act with
the client's authority in some circumstances
(e.g. writing the compiler output), it may
not have the information it needs (e.g. which
other capabilities not to combine with that
communicated form the client) to enforce this
restriction when desired.

This potential for confusion has nothing to
do with the operation of the deputy.  That
operation may indeed influence whether or not
the client may be able to actually extract
any additional authority from the deputy
or not, but the resulting environment is
what Toby's statement (my slight mod) focused on:
_______________
In any case in which a service may get more
authority than its client from an added capability,
the service is potentially confusable by that
capability sent from the client.
_______________

Does the apparent clash result from my
focusing on the environment of the deputy
and you focusing on the operation of the deputy?
Do you still feel that above statement
to be devoid of meaning?

Hmmm.  One thing I just realized is that,
while I still believe Toby's statement is
true and meaningful, I don't believe it
is comprehensive in a way I hadn't previously
considered.

In particular, it may be that the service
already has the authority that the communicated
capability can inappropriately be used to grant.
In that case one would say that the service didn't
"get" more authority than the client by the
addition of the communicated capability, but
it still may be in a situation where it can
be "confused" into granting more authority
than intended when acting on the client's behalf.

I'm not sure how to capture that subtly, but
I think I won't try that here in this already
overly long message.

I believe I fully understand your point that if
the client has the capability and the ability
to communicate to the server, then the client
already has the potential to perform whatever
operations may be available to it by exploiting
the possibly confused server, and thus that the
client's "authority" includes all such possible
operations.  However, we can still imagine the
client without the capability, the server
without the capability, and then the situation
that can arise if the client communicates the
capability to the server.

It is certainly true that a deputy (server)
may, with poor programming, be "confused" by
a request into granting more of its authority
than its author intended in response to that
request.  This situation is of course a common
concern with servers.  This situation can arise
even without the problem the "Confused Deputy"
faces of not being able to tell what authority
it has FROM the client that it can use on the
client's behalf without granting the client any
additional authority.

The unique aspect of the "confused deputy"
problem is caused (I believe) by the
environment the deputy finds itself in with
respect to a communicated object reference
(of course the prototype case being a reference
that is separated from the authority to access
the object).  If the deputy is unable to act
with just the authority of the client when it
intends to, then it is an environment that can
lead to confusion.  Any sort of "Rights Amplification"
can of course lead to such a situation as the
deputy may not know how it must specially treat
the communicated capability so as to not unintentionally
increase the operations possible on it with the
deputies own - what, power?  Norm used the term
"authority".

I hope this discussion gets us closer to agreement,
but I fear the opposite.  Sorry, I'm doing my best
here.  I wonder if an interactive discussion might
help?  510 486-4155

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