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

Christian Skalka ces@blaze.cs.jhu.edu
Fri, 19 Jan 2001 15:01:46 -0800


Your points are well taken.  The real reason I make this distinction
between policy and principle is because ACL's plus stack inspection
is not a model that can only be used in Java.  That is, it is possible
to design a new language from the ground up, using ACL's and
stack inspection (in fact, we began this process in our last two
papers).  The sins of Java need not necessarily be repeated in a
new language, as long as their source is the policy and/or implementation
details of Java.

This is really the question that Scott and I are asking: in a _foundational_
sense, is there a significant advantage of capabilities over ACL's plus
stack inspection, or vice versa?  That is why we are more concerned
with flaws in principle rather than in policy.  There's a lot more that's
bad about Java than the security mechanism, but from my perspective
I'm happy to see it as a shed skin on the road to developing a really
sound language, if you know what I mean.  This is the result of working
in a theoretical world, rather than a real programming world as you
do; our notions of "significant flaws" are not surprisingly divergent

But the goal of our theory is to provide something that works for
real programmers, so your insight is helpful.  Indeed, your example
cites the need for a mechanism that dynamically updates the ACL (see
my psuedocode), which is something we've wondered about and in fact
have not included in our previous models: it complicates matters
significantly.  If this is a common case, then it may well be an example
of a superiority (in principle) of capabilities over ACL's plus stack


Marc Stiegler wrote:

> > Note that the object will give the user read and write access to only one
> > file, the file specified by the text editor during the first invocation of
> > FR.GetFileAccess.   This is enforced by the private instance variable
> > FileGiven, and by the fact that only one instance of class safeFileReader
> > may exist for any given process.  Thus, I think this is a solution to your
> > problem, which again constitutes a change in policy.  It is a fairly
> hackish
> > solution, however, and I'll bet that capabilities would at least be
> simpler
> > in this instance.
> Indeed, it brings us close to asking the question, where does policy end and
> principle begin, because, while these two are often clean distinctions, one
> can find the line between them sometimes. The particular thing which is
> egregious to me about the Security Manager is that it cannot generally
> mediate a grant of privileges in a user friendly way. User friendliness is a
> wildly underappreciated element of successful security. You must make it
> friendly enough so that people will both use it and--even more
> underappreciated--understand it. My biggest heartburn with the Security
> Manager as it is used in the browsers today is actually not the grotesque
> choice of granting total authority over your file system, or no file access
> at all. Even worse than this horror is, I with a Masters in CS do not fully
> understand the consequences of the security manager settings. How would a
> normal person deal with it? The caplet launching process in development for
> E, on the other hand, looks like an absolutely ordinary man/machine
> interaction. The only difference is that the user is the king, making grants
> ("you are allowed to access this") rather than the humble supplicant, making
> requests ("please let me edit this while you are playing with all the other
> files on the system").
> If I understand your code correctly, you are more or less spotting the
> authorized file off the command line, and your solution works fine in this
> case, and it's cool. But more generally there are 2 other natural ways for
> people to specify a file: via a FileDialog and via drag/drop. But we cannot
> trust the app to interpret these actions correctly--to work properly, the
> app should ask the Security Manager to pop the dialogs and handle the
> drag/drops.
> So we could extend the Security Manager to have calls which the app can make
> to it, and calls which the Security Manager can make back to the app, such
> that the Security Manager pops the dialog, and the Security Manager detects
> and handles drag/drops. Now, if the Security Manager were changed to support
> these behaviors, would we have merely changed policy, or would we have
> changed principle? Would the Security Manager be evolving ever so slowly but
> surely into a capability manager, comparable to the caplet-launcher I am
> building for E? Especially if we expanded the Security Manager to enable
> realtime addition/deletion of every capability in the system, which is
> really what you need in the general case?
> Regardless of the answers to these philosophical questions, the truly
> serious question is, what are the chances of JavaSoft implementing such
> changes to the Security Manager? Perhaps, in the end, that is where the
> question of policy ends and the question of principle begins: if it requires
> JavaSoft make an improvement in the software, you're toast, and it is a
> matter of principle :-)
> --marcs

Christian Skalka
Dept. of Computer Science, Johns Hopkins University