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

Scott Smith scott@cs.jhu.edu
Fri, 19 Jan 2001 15:03:44 -0800

[forwarded with permission.  --MarkM]

Lets map capabilities on to some real-world scenarios.  Credit cards. 
Taken as a pure capability all you need to do is present the card, you
can pass the card around if you want, presenting it buys anything, etc. 
But they don't work that way.  Signatures/photo ID/... are needed as
non-capability cross-checks.  This is my entire point: cross-checks to
capabilities are needed.  More interesting is how credit-card
transactions have been evolving in the on-line world.  There they
started as pretty much pure capabilities in that no signature is
required, only the number.  But, you now must give a billing address. 
Still, there has recently been a wave of fraud through on-line credit
cards, and further controls are being added.  Just yesterday a company
wouldn't ship me something I ordered on-line because I wasn't in their
phone book (I moved about a year ago).  So they required me to fax my
driver's licence with my address on it to them.  Its interesting that
when I called the company it was to the "department of order
verification", so now they have a whole department engaged in capability
verification! Also I have had webpages require me to enter some control
codes on the card, which are not part of the number (thats a stupid idea
in the long run because eventually thieves will capture those too). 
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).  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.  There are similar
cross-checks on other capability systems in the real world.  Passcard
computer access devices can require both the card plus a password or
fingerID.  The fact that the real world has not embraced the idea of
pure capabilities gives some evidence that it is an insufficient model. 
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.  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.

One other thing: I don't equate ACL's and stack inspection by any
means.  It should be possible to define a capability-based notion of
stack inspection on top of a standard capability model.  Just replace
privilege with capability (this was in fact the Java-folk's original
terminology: search for "capability" in
http://home.netscape.com/columns/techvision/java.html).  So, every
object has a fixed capability set associated with it (say initialized at
load time) which is added to its method's stack frame.  What
checkprivilege(cap) does is scan back on the stack to make sure every
call on the stack also has capability cap in the frame.  Ignoring
network issues for now, in the communicating conspirators example Mallet
can get a capability at run-time, but if he tries to do something with
it that raises a checkpriv(cap), his code doesn't have cap and the
checkpriv will fail.  ... This is super-vague but I hope you at least
see there is no necessary relation between ACL's and stack inspection.  

The general approach needed in my (not completely well-formed) opinion
is a broad family of techniques for modulating capabilities.  The bigger
the basket of tricks, the greater the security possible.  Some are
easily encoded in capabilities themselves, such as restricted feature
capabilities (subset of a full capability via a wrapper), timed
capabilities, revokable capabilities, coordinated capabilities (requires
two parts to get the real capability), etc (is there a good listing of
these things somewhere??).  But some modulating dimensions are not
easily encoded in capabilities, and stack inspection is one such

(I'm leaving for a week so expect slow/no email response shortly)
(forwarding to elist fine)