[E-Lang] ACLs + delegation

David Wagner daw@mozart.cs.berkeley.edu
1 Feb 2001 06:08:25 GMT


Mark S. Miller wrote:
>Compared to capabilities, like SPKI, it is incapable of confinement, and, 
>because it separates designation from authority, is vulnerable to confused 
>deputy.  As explained in the CapCert thread (I can find the message if you 
>wish), because it separates authorization from invocation, it's vulnerable 
>to confused deputy again.

Yes.  I must admit I haven't thought about confinement (in the Lampson
sense of eliminating covert channels), because I frankly feel that the
best answer to the confinement question is to unask the question.  But
that's a matter of personal taste and a different tangent entirely.

As for the Confused Deputy problem, I profoundly agree with this argument
against making the protection decision depend on implicit state.  However,
my response is a bit different from yours, I think.  Rather than concluding
that the only answer is a capabilities systems with the added property
that designation is unified with authority, I think there's also another
useful response to the Confused Deputy problem: Insist that all security
relevant operations make explicit under what authority the action is being
requested.

For instance, if we consider the Unix open() call, my explicitness proposal
would have it be changed to have the following interface:
   int open(uid_t authority, char *file, int flags, ...);
Here, the open() call would be done as uid 'authority', rather than as
geteuid() or getfsuid() or whatever.  Today's common idiom
   seteuid(authority);
   fd = open("foo", ...);
   seteuid(getuid());
becomes, in my world,
   fd = open(authority, "foo", ...);
This provides a level of explicitness that seems to go even further than
what you get if you combine designation with authority: Under my
explicitness proposal, you get a double cross-check between the authority
and the designed object.  By making the authority explicit, it provides
a form of documentation of what authority the programmer intended to use
for this operation, and one that will be cross-checked against the object
the programmer tries to open.  This cross-check is not present when you
combine authority with designation.

In some settings, the requirement for extra explicitness may be
annoying clutter (esp. if we consider operations that are done extremely
frequently).  In other settings, the explicitness may be a benefit for
security.

I suspect it is application-dependent whether my explicitness principle
is a boon or a bane, but I mention it as an solution to the Confused Deputy
problem that seems to provide a second alternative to the solution proposed
on this list (use a capabilities system extended so that designation is
combined with authority).