[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaandScottSmith of Johns Hopkins)

[Bill Frantz]

At 05:28 AM 2/1/01 GMT, David Wagner wrote:
>Note that the model of an access control system used in their paper
>was agnostic about how access rights are stored.  (If they are stored
>with the subject, you get a capabilities system; if stored with the
>object, you get an ACL system.)  Thus, it seems to me that their
>results apply equally to both capabilities and ACL systems.

I think this formulation is subtilely wrong.  If you bind the access rights
with the name of the object, you have a capability system.  If you store
the access rights with the subject, you get an SPKI like system; where you
have to use both the name (to locate the object) and the access rights to
perform an operation.  If, when you access an object, you always pass all
your SPKI certificates, then you have a classical Unix style ACL system
(with the access rights stored with the subject).


In the "Re: [E-Lang] ACLs + delegation" thread, several minutes later,
David wrote:

>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.

My first reaction is that this approach greatly increases the programming
complexity of programs which use it.  Increased complexity of mechanism
will not encourage people to program with the principle of least privilege.

It also seems to me to describe a system where a program can chose which
subject to act under dynamically at run time.  If I am giving a server
access to one of my objects, it can keep my subject-id, and use it later
for other objects, even after I have deleted the object I wanted it to use.
 (Stack introspection could prevent this problem if the server is run as
the result of a call in my thread.  Introspection doesn't help if the
server is running on a different thread, or a different machine.)

(Highly dynamic subject creation gets into the problems Ping described.)