[E-Lang] Java 2 "Security" (was: Re: Welcome Chris Skalkaand ScottSmith of Johns Hopkins)

Jonathan S. Shapiro shap@cs.jhu.edu
Sat, 20 Jan 2001 07:37:46 -0500

> > Anyway the war being fought as we speak shows how the credit-card
> > capability needs to be supplemented to be secure (n.b. it is already
> > revocable).

I don't think so. First, I don't think any of us have argued that
capabilities are the only possible mechanism. Rather, we have argued
that they appear to be the only mechanism that *works*. The problem with
all of these cross-checking notions is that they all rely on public,
easily obtained information. Easily obtained for the criminal as well as
the vendor. That is: most of the cross checks provide no security

> > Capability systems are certainly stronger than on-line
> > credit cards, but they are not much stronger than a physical credit card
> > which requires no extra authentication to use.

I agree, but there is an important subtlety in this example. The reason
a credit card is so powerful is that it is a capability to an object
denoting other capabilities (dollars). In general such objects are very
powerful and must be treated with great care. The problem with a credit
card is not the fact that it is a capability. It is the fact that it can
be stolen (or more accurately, the fact that in the physical world it
cannot be adequately protected).

If we move to a world where electronic devices sign transactions, the
entire problem you describe goes away. The solution, then, is not to
introduce ineffective and vacuous additional checks, but rather to
provide means by which sensitive objects can be adequately closely held.

> > The fact that the real world has not embraced the idea of
> > pure capabilities gives some evidence that it is an insufficient model.

In matters that are technically complex, the accumulated opinion of
people who really don't understand the issue says nothing about the
merits of the idea. Only about the merits of the public relations around
the idea.

> > Certainly capabilities are the core of much real-world security, but
> > they are not the only aspect.  Even if capability code is itself
> > well-written, in a complete system there will be some users indirectly
> > controlling some capabilities who are bound to screw up.

I find that it is helpful to distinguish between things that render
security feasible and things that render it usable. The latter is
terribly important, but it is never a good justfication for overriding
the former.

Users are very clever. Therefore, one can rarely anticipate all of the
ways in which the user can go wrong. One should probably seek a
reasonable compromise to mitigate high-likelihood errors. An example of
a good tool here is forcing the manipulation of authority to be explicit
rather than tacit in the program. As an illustration: in UNIX, authority
is process-wide and never specifically identified at the location where
the operation is preferred. in EROS, authority is also process wide, but
every invocation clearly identifies the authority by which it is acting.

In practice, the only cases I have discovered where a multiplicity of
mechanisms is appropriate and workable are cases where one wishes to
introduce a policy that depends on the semantics of the data. Such
policies inherently cannot be interpreted by the kernel -- the kernel
cannot know these semantics. The problem is that data has a way of
leaking, so higher level policies of this kind have a way of being

> > If you think
> > users will not be able to control capabilities, then you have users who
> > hate you because they can't do anything useful with their computer.

This argument seems flawed, because it does not consider the cost of the
alternative. Such users should use Windows if they prefer it. If the end
up naked and freezing because somebody nailed their bank account, they
should not then complain to me.

We need to make this stuff usable, but in doing so we must not err by
creating false/unenforceable security policies. If by "techniques for
modulating capabilities" you mean software and design patterns that
assist the programmer in manipulating and transferring capabilities
correctly, then I entirely agree with you that we need these. I don't
agree that a "bigger basket of tricks" is better. I think that what is
best is a small basket containing the *right* tricks.

The trick, of course, is to discover these in time. :-)