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

Tyler Close tclose@oilspace.com
Fri, 2 Feb 2001 15:36:20 -0000

David Wagner wrote:
> Tyler Close wrote:
> >David Wagner wrote:
> >> You mention a second criticism: that one has to decide
> which objects
> >> will be guarded by ACL's.  Well, that may be true, but
> why is it a
> >> problem?
> >
> >So, I feel very nervous about this given your reputation, but this
> >would suggest to me that you haven't written much
> software. Maybe one
> >of the Javasoft guys could tell us how much time was spent on this
> >issue for the Java APIs. I'd also be interested to hear if
> they think
> >they got it perfectly correct.
> I still don't understand.  ACL's are just a mechanism.  You need to
> start with a security policy, and if that policy doesn't
> give you enough
> information to decide whether a particular object needs to
> be guarded
> in some way, it seems the right answer is to get a better policy.

The security policy cannot be fully known at the time that the code
for specific parts of the system is written. "Starting with a security
policy" is not a realistic assumption. This means that individual
parts of the system must be coded such that they are capable of
enforcing a wide range of possible security policies.

The ACL model requires that the invokee check access. This means that
there must be a statically known list for the invokee to check. The
types of security policies that can be supported is limited by the
interface to this ACL.

If programmers in an ACL system stuck with the policy that every
distinct authority be given its own seperate delegation supporting
ACL, then the resulting design would be able to represent all possible
states of the access table for the application. The ACL model does not
enforce, or even encourage this behaviour. Instead, an ACL system
promotes the creation of ad hoc ACLs that are not capable of
representing all possible states of the application's access table.
Hal's Mint is a recent example of this.

Given the duplication of work that the ACL model requires (once to
authorize it, once to do it), creating ad hoc ACLs becomes a necessity
in order to make the application useable. Hence, there is a tradeoff
between security and useability.

This tradeoff does not exist in the capability model. By merging
designation and authorization, the capability model effectively
ensures that there is the equivalent of one ACL for every distinct
authority in the application. It is therefore guaranteed that the
design will be able to represent all possible states of the
application's access table. This means that it is possible to code a
given authority without knowledge of the final application's security

The capability model is able to provide this level of security
functionality without impacting on application useability, since it
does not demand the duplication of effort that the ACL model does.
Passing authority requires only a single action.

This is one argument in favour of the capability model over the ACL
model. It is a good one, but it is not the best one we have.

The rest of this message is just some specific rebutals to specific
comments. There is no new content.

> If that's true, it's a flaw in the particular implementation, not
> a fundamental limitation of ACL's.  (And yes, it is also possible
> for an implementation of a capabilities system to have this flaw.)

It's a flaw in the view of application security that the security
model provides. The ACL model is action centric, not authority
centric. It therefore encourages the incomplete modeling of the
application access table.

> ACL's aren't magic bullets.  They don't automatically make your
> system secure.

Capabilities are not magic bullets either, but they do automatically
make your system secureable. An ACL design may not be secureable due
to an incomplete model of the access table.

> >Even the little MintMaker example is all about access
> control at the
> >granularity of pointers. Without it, you fall to the
> confused deputy.
> I don't understand.  It seems to me that it is about access control
> at the level of *accounts*.  That's different.

How do you distinguish an account from a pointer to an account object?

> >Initially, this made no sense to me whatsoever. Then I
> read Jonathan's
> >response and saw that you mean for the Subject ID to be a
> capability.
> Sure, you can think of it that way if you like; it doesn't
> bother me.
> I don't really care what you call it -- I find it more
> interesting to
> try to understand the properties of the security mechanisms
> available
> to us.

Only by attaching correct names to concepts can we understand which
security mechanism we are talking about. In this case, you were not
naming the concept that you were using, but you were borrowing its
properties for use in another mechanism. Surely, you understand that
this confuses the understanding of what security mechanism is being
analyzed, and what properties it has. How would you categorize your
proposal? Are the properties it exhibits properties of an ACL or
properties of a capability? The answer to this question sheds light on
which mechanism is actually more appropriate to solving the problem.