[cap-talk] Confused Deputy, multiple authorities - Norm?

[Jed at Webstart]

At 04:48 PM 10/24/2006, David Wagner wrote:
>Jed writes:
> >"The billing information file (SYSX)BILL was also stored in SYSX.
> >Some user came to know the name (SYSX)BILL and supplied it to the
> >compiler as the name of the file to receive the debugging
> >information. The compiler passed the name to the operating system in
> >a request to open that file for output. The operating system,
> >observing that the compiler had home files license, let the compiler
> >write debugging information over (SYSX)BILL. The billing 
> information was lost."
> >
> >If the compiler could know the users UID it could check to insure
> >that the user had write access to their debugging information file.
>[...]
> >In the case of Unix with SUID I believe the problem is more
> >subtle.  In the Unix case an SUID application can get the original
> >UID of the user and to a large extent can determine if an action
> >would be beyond the authority of a user.
>
>It's not quite that simple, because of TOCTTOU attacks (race conditions).
>If you check that the user should have write access, then go ahead and
>perform the write if the answer is yes, you might discover that the user
>briefly had access at the time when you performed the check but didn't
>have access by the time you did the write, because the file changed in
>between...

Understood.  From my viewpoint you (later) describe what is considered
a safe way to "determine if an action would be beyond the authority of a user."
as I note above.  To me you seem to be describing another level
of detail.  I agree this detail is important, but I don't think it appears
at the level I was discussing.

Regarding:

>Beware that while the standard advice works for programs that are
>setuid-root, it may be difficult or impossible to implement for programs
>that are setuid to a non-root user (or are setgid).  In general, Unix's
>support for setuid-non-root programs is poor.

The above might be considered when looking for the impossible
Confused Deputy situations (in Norm's narrow sense of not being
able to determine the client's authority) in Unix.

> >With parameters that confuse it (e.g. command lines too long), buffer
> >overflows of any sort, etc., etc.  I'm surprised you ask that
> >question.  If the passwd command can be induced to change a password
> >other than the user's, then the passwd command has been
> >"confused".  I believe there have been just such instances of
> >confusion in the passwd in the past, though I don't have an example
> >at hand.  Such confusion is certainly possible.
>
>Please don't use the word "confusion" for this.  You've equated the
>word "confusion" with any and all security vulnerabilities, which just
>eliminated all descriptive meaning in the term.  Buffer overruns are
>not an instance of the confused deputy vulnerability.  The confused deputy
>problem is a very specific class of vulnerabilities, and buffer overruns
>aren't it.  Using the word "confusion" to refer to buffer overruns is just
>confusing.

Hmmm.  Here we may have a point of disagreement on principle/definition.

What I mean by "confusing" the Deputy is any means by which the
client can get the Deputy to exercise authority on the client's behalf
that is beyond what the design of the Deputy would intentionally
authorize for such a user.  Consider a database server.  Assume for
the moment that a database server can correctly associate a given
client with a given "user" (assuming the typical user arrangement like
used by Oracle, Postgres, and MySQL as examples).  The database
server has file level access to the entire database.  It has rules that
it applies to tables, etc. with roles, etc. that allow some users some
access and others different access.  What I mean by "confusion" in
this case is any means that the client can use to get the service
to grant authority beyond that intended by the user model within
the database scheme.

When you say that the "confused deputy problem is a very specific class
of vulnerabilities" it seems that you are using the term in a narrower
sense than even I suggested with the narrow sense, namely:

Date: Tue, 24 Oct 2006 13:30:03 -0700
To: "General discussions concerning capability systems." 
<cap-talk at mail.eros-os.org>
From: Jed at Webstart <donnelley1 at webstart.com>
...
>We could ask whether the term "Confused Deputy" should be limited to 
>the case where the Deputy has no way to determine what the 
>appropriate authorization for the client is or whether the "Confused 
>Deputy" should apply to the more general case.  I believe the 
>Wikipedia article is using it in the broader sense.
...

If you are indeed using the term "Confused Deputy" in a more narrow 
sense, could
you describe or point to the "very specific class of 
vulnerabilities"?  Norm's example
is very specific where the Deputy in fact can't know the authority of 
the client.
Is your thinking that the "Confused Deputy" should be limited to that case?
That's what I was asking in my previous message.  In that case I 
think I would like to
have a term for the broader case.  Perhaps it's so broad as to 
include all "security
vulnerabilities"?

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