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

[Christian Skalka]

[forwarded with permission.  --MarkM]

Hi, I wanted to respond to this posting but it's over two weeks old, so I figured
that I'd do it personally and not over the mailing list.  Sorry about the delay but
I've just recently had the chance to review some of these messages.

I think there are two levels on which to critique the Java2 security
architecture.  One is an essential level; that is, what the model is capable or
not capable of expressing in principle.  The other is a policy level; that is,
the particular post-hoc policies the system enforces.  A shortcoming in principle
is obviously worse than a shortcoming in policy, since the latter can be eliminated
by a revision of policy, using mechanisms intended for this purpose.  I will give
examples of what I mean below.

Marc Stiegler wrote:

> Browse the Web, find a text-editing applet/caplet with good reviews (or a
> text-editing app written by a malicious cracker, hey, the editor could fall
> in both these categories at the same time :-). Load the app on your local
> machine, specify the local confidential file you want to edit (location and
> name of the file to be specified in real time, with a file dialog or drag
> drop or some such thing), edit the file and save it to the same place. At no
> time be at risk of having the foreign-born text editor compromise the files
> in your operating system, at no time be at risk of having the data in this
> confidential file--or in any other confidential file--leaked from your
> machine.
>
> Until we have systems that allow this ludcrously simple security problem to
> be solved, we can never have serious security. Yet I believe that Java 2
> still has at least 2 fundamental flaws for this scenario:
>
> 1) Java applets get a connection to the server-of-origin by default, meaning
> your confidential data is free for the asking to the people who posted the
> editor on the web;

It is true that the policy of Java dictates that _applets_ can call back to their
server of origin.  But there is nothing to prevent us from creating a new
class of programs called, say, "non-locals", along with the policy that
non-locals cannot send any messages from your machine.  Then, you may
locally categorize the program as non-local, rather than as an applet.  This
revision-- or rather, addition to-- policy will solve the problem.  Alternatively,
you could just revise the applet policy to disallow message sends entirely.

> 2) The Security Manager has no way of interacting in realtime with either
> the file dialog boxes, or the drag/drop system, or any other
> file-designation tool, to allow it to work cleanly with the user to grant
> read/write authority to a single file of the user's choosing but no others.

This seems like a deeper problem to me-- that is, a possible shortcoming
in principle.  In fact, if we take the view that access control lists are fixed,
then there can indeed be no solution to this problem.  However, let's assume
that access control lists can be dynamically updated.  Also, let me note that
privileges in Java2 are first class, and paramaterized privileges exist.  That is,
we may create a privilege of the form FileRead(fn), where fn is some file
name.  So, here is a rough draft of a solution to this problem in psuedocode.

Let's assume that there exist file read and write functions sysFileRead and sysFileWrite,
and the function AddToACL which updates the access control list, which are available
only to the local system.  Then the system may, during initiation of the non-local
text editor process, instantiate a single instance FR of the following class for
granting safe access to a file:

class safeFileReader is:

private bool FileGiven := false;
private string FileName := "";

public string SafeFileRead(filename)
{
   checkPrivilege(FileRead(filename));
   return sysFileRead(filename);
}

public void SafeFileWrite(text, filename)
{
   checkPrivilege(FileWrite(filename));
   return sysFileWrite(text, filename);
}

public void GetFileAccess(filename)
{
  if (FileGiven and filename != FileName)  { fail; }
  else
  {
    FileGiven := true;
    FileName := filename;
    AddToACL(principal, FileRead(fn));
    EnablePrivilege(FileRead(fn));
  }
}

end

We will also assume that the system removes any FileRead privilege
created in GetFileAccess at process termination.

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.

-chriss


>
>
> And then there are the problems with window forgery completely unconsidered
> with the Java 2 Security Model, which I will also have solved in a couple of
> months for E caplets.
>
> Lastly, I do hope everyone understands that the ability to "sign" applets
> and applications has nothing to do with security. Signing apps is what
> marketing people propose when technical people explain that real security is
> not possible; it allows the tool developer to blame the victim when a signed
> app engages in malicious action (hey, the victim authorized the app, didn't
> he? It's his own fault).
>
> Hopefully this constitutes enough examples of what is wrong with Java 2 so
> you can stop treating it like a serious undertaking :-)
>
> Though I do not discuss Java 2 directly in the book E in a Walnut, you might
> want to read the chapter on Secure Distributed Computing for a discussion of
> interesting security issues, each issue making available a Question For The
> Reader, "can the Java 2 security model address this?" Find the book draft at
>
> http://www.skyhunter.com/marc.html
>
> In answering questions of the form, "can the Java 2 security model address
> this?", also remember that a complicated system cannot be a secure system.
> There are some problems which Java 2 can nominally solve, but only by
> introducing sufficient additional machinery and mechanism that you have to
> ask, "did I violate the requirement for simplicity?"
>
> --marcs
>
> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang

--
Christian Skalka
Dept. of Computer Science, Johns Hopkins University
ces@blaze.cs.jhu.edu
http://www.cs.jhu.edu/~ces