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

Marc Stiegler marcs@skyhunter.com
Fri, 19 Jan 2001 15:01:21 -0800


[forwarded with permission.  --MarkM]

> 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