[cap-talk] Whether principals' authority can increase

[Marcus Brinkmann]

At Wed, 24 Sep 2008 09:55:11 -0700 (PDT),
David Wagner <daw at cs.berkeley.edu> wrote:
> Marcus Brinkmann wrote:
> > A system in which principals can only ever diminish their authority
> > and never increase it does not sound too useful to me.
> [... and later ...]
> > Sorry, I misspoke.  I meant to say "a system in which a principals
> > authority can never increase", by whatever action.
> 
> I don't think that's an entirely accurate description of an object
> capability system.

It was not meant as such.  I took it (maybe wrongly) that the confused
deputy was used as a distinction criterion between capability and ACL
based systems: I got the impression (I don't know from where, I was
probably being careless) that a common claim is that in a capability
system, confused deputies are impossible, while in ACL systems they
are possible.  I think the careful analysis shows that they are
possible in either type of systems, but that they may be easier to
avoid in capability systems.

I am willing to agree with that latter statement, but I am not sure
about the quantity of the advantage.  At least we know that in Unix it
is possible to implement a correct program that avoids the confused
deputy problem (even if it may be a more error-prone process).

> I should also say that it seems strange to say "a principal's
> authority".

With "principal" I meant "user." 

> > If a powerbox exists, the user can be a confused deputy.  For example,
> > a mail reader can request the powerbox to execute an attachment, and
> > the user may authorize this action against his own interest.
> 
> The essence of confused deputies is not making a bad decision about
> whether to authorize or not (in code, that's just a logic error).  It
> seems to me the essence of confused deputies is wielding the wrong set
> of permissions (the wrong source of authority) when performing an action.
> In a confused deputy situation, if only you had wielded the proper source
> of authority when performing the action, you would have been secure.

Right, I was confused.  That's a great way to put it.
 
> I don't immediately see how that applies here....

It doesn't, after all. :-/
 
> Also, I would say that it seems to me like it would not be good UI
> design to ask the user a question like "The program is requesting to
> do such-and-such; is that OK?": that's too likely to lead to a user
> clicking OK without thinking about it.  Rather, the objcap proponents
> tend to advocate for UIs that turn things around the other way: they
> wait for the user to request some action, and then infer (based on
> the fact that the user explicitly requested it) infer that it should
> be allowed.  For instance, they might allow the user to click "Save
> as" and select a file using a file open dialogue, and then infer
> that the process should receive a capability to that file.  That's
> quite different from popping up a dialogue box to the user saying
> "The program wants to save this file as foobar.baz; is that OK?";
> the latter seems more likely to lead to insecurity.

Where this is possible, I agree it is nicer.  Not because it is more
secure, but because it is more convenient.  But can you avoid it
always?  I can think of two ways how programs may want to initiate
actions: Either they have a delayed response to a previous user
action, or the authorizing user action was done inside the
application.  Example for the first way: The user authorizes execution
of a script program FOO, which includes other source files BAR, BAZ,
etc.  Example for the second way: The FireFox browser asks the user in
a dialog if it wants to import bookmarks from Internet Explorer.  The
user authorizes the action, but the powerbox does not know that this
authorizing action occured and needs to ask for confirmation.

You can solve these issues by putting more functionality of the
application into the powerbox, but this is not a scalable solution.
You may end up moving most of the functionality into the
shell/powerbox, defeating POLA.

The problem is that if you admit *one* exception, you can not prevent
malicious software from exploiting it the way you described.

Thanks,
Marcus