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

Tyler Close tclose@oilspace.com
Mon, 29 Jan 2001 15:15:19 -0000


Jonathan wrote:
> 	(domain, object, permissions)

Is it correct to rename these entities to:

	( invoker, invokee, vtable )

Where vtable, is merely a listing of the message types that invoker is
authorized to send to invokee.

> The nominal differences between ACLs and capabilities lie
> in two places:
>
> 1. Which way the table is factored (object centric vs.
> domain centric).
> For understanding the respective power/weakness of the
> models this is a
> complete non-issue. The factoring of the table is purely a matter of
> storage and referential efficiency.

If my understanding of the access table triplet is correct, then I
disagree, emphatically. In fact, I think it's the main issue, not a
non-issue.

Confused Deputy
---------------
Putting the authentication check at the invokee necessarily means that
designation and authority have been split. The main lesson of the
"Confused Deputy" is that this division is done at great peril. An ACL
system requires this division for all invokees of interesting power.
This means that everything of interest in the application is open to a
confused deputy attack.

Loss of Flexibility
-------------------
Putting the authentication step at the invokee means that the security
policy for the invokee is set in stone for its entire existence. For
example, in Java this means deciding which methods may throw a
java.lang.SecurityException. As I said before, this is a non-trivial
decision. Moreover, for the protected methods, it requires that the
invokee know, at the time that it is coded, either what invokers are
authorized, or by what process they may become authorized (so that it
can check that they are authorized, by, for instance, checking a
SecurityManager). Much of creating a secure application is about
creating new ways in which invokers may become authorized to send
particular messages to an invokee. The invoker centric approach
destroys this flexibility. Markm also pointed this out when he replied
to David:

"In order for ACLs vs Capabilities to be a semantic difference, they
must be
defined in terms of how the permission to change permission is
aggregated,
when such permissions to change permissions are held by mutually
suspicious
parties."

I contend that the ACL approach requires a static mechanism for the
"permission to change permission". If the mechanism is not static,
then the mechanism itself requires another ACL to guard access to its
methods, and so on, for infinity. At this infinity is an invokee
accessed only by a capability (ie: an invokee that allows all invokers
capable of sending messages).

Subtle security issues in the implementation
--------------------------------------------
In addition to the storage and referential efficiency implementation
issues, there are also significantly complicated security issues.
Putting the access check on the invokee requires one of two things.
Either the invokee has only one facet (vtable), or each invocation
must be accompanied by the full access table entry that authorizes its
delivery. In the latter case, the invokee must check that the
invocation comes from an authorized invoker AND that the message is an
element of the vtable that the invoker has been authorized to use.
This second check seems particularly problematic to implement.

> 2. Which operations and commands (see Harrison, Ruzzo, and
> Ullman '74:
> "Protection in Operating Systems") exist in the environment
> to update
> the table.

And how access to these operations and commands is granted. For the
system to be flexible, there cannot be any magic superhuman overseeing
all authority flows. Proponents of ACL systems seem to believe in the
viability of gods.

The granularity at which these commands can be invoked is also of
great importance. The authority to make modifications to the access
table for an entire application is not a useful authority. Who in the
application would be given this authority? It is only feasible to
assign principals fine grained authorities. Breaking down authority
over the access table into useable pieces, results in the creation of
authorities that are so specific that they are tightly coupled with
the operation that they authorize. I contend that this process either
results in the creation of capabilities, or an application in which
everything is done twice (once to authorize it, once to do it). Surely
verbosity doesn't imply security. I believe it hinders security, since
it encourages the designer to define overly broad authorization
actions in an attempt to save labour.

The ACL is a deeply flawed security architecture. It is only similar
to capabilities in terms of the goals it tries to achieve. An access
table can describe the authority partitioning of an application, but
it is how this table is modified and used that is of crucial
importance. ACLs and capabilities take two completely different
approaches to this task.

Tyler