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

Scott Smith scott@cs.jhu.edu
Sat, 20 Jan 2001 11:25:06 -0500


"Jonathan S. Shapiro" wrote:
> 
> > > 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
> whatsoever.
> 
I take issue with "no security whatsoever".  My opinion is security
should not be defined as an idealized concept.  Security "works" if the
tax of the break-ins plus the hassle of the security policy is
tolerable.  Too much security is just as bad as too little.  So, in this
sense the cross-checks do work today because they statistically cut out
a lot of fraud.  ANY security system ultimately boils down to statistics
on how many violations happen and their cost, NOT to some proof of
correctness, because every security system lives in this universe with
real people and computers, not in a mathematical universe.

> > > 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).
> 
When users are directly manipulating capabilities the same problems will
arise.  My guess is a good chunk of stolen credit cards were first
misplaced by their owner.  "Oops, attached the wrong capability to that email!"

> > > 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.
> 
No, they aren't going to care that much because their transactions were
insured.  The banks and insurance companies are the ones who are going
to care and they are going to want uniform standards.  So there will be
a tension between users and these authorities.  Jonathan, you already
know about this tension because you see it between our department and
the campus security people who have many somewhat annoying restictions
in place.

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

Agreed!  Stack inspection is just a fancy design pattern.

:-)

By the way, Ben's question about a real example of what stack inspection
could add to capabilities is a good one (so far I have only toy
examples) and we'll be thinking about it.

Cheers,
Scott