Security in libgcj

[Tom Tromey]

>>>>> "Stéphane" == Stéphane Konstantaropoulos <stephane@cs.york.ac.uk> writes:

Stéphane> I am working on an implementation of an Gecko/OJI plugin based on
Stéphane> libgcj. My goal is to specify formally the whole security aspect of
Stéphane> loading classes and executing them.

Awesome!

BTW, do you know about gcjwebplugin?

Stéphane> - Do you aim at implementing the Java2 model? (with fine-grained
Stéphane> permissions) if so, where are the permissions stored (like in
Stéphane> $JAVA_HOME/lib/security or something)

We do plan to implement this.  A fair amount of the code is there,
almost all of it, I would say.

See gnu/java/security/PolicyFile.java to see how the default policy
is found.  It appears to be $JAVA_HOME/lib/security/java.policy

Stéphane> - Is the Security manager a concrete class that respects those
Stéphane> permissions?

Reading through SecurityManager, it looks like there are a few
unimplemented bits.  There are also a few required security checks
that we do not perform; some of these are marked (and, I suspect,
some may not be).

Stéphane> - Will any class loaded with URLClassLoader or another ClassLoader be
Stéphane> submitted to SecurityManager checks if it is natively compiled? (This
Stéphane> would be nice!)

Yes, this should work in the cases that matter.

Stéphane> - How does it work internally? ie how does it isolate Security contexts
Stéphane> and how does it keep track of the call stacks to find which class is or
Stéphane> isn't allowed to do such and such things?

There is low-level code to walk the stack, on Linux using the same
unwinder that exception handling uses.  Then we map from the method to
its declaring class, and from there we can find the protection domain,
class loader, etc.  See stacktrace.cc for the gritty details.

With the binary compatibility ABI, the mental model I have is that we
are just loading classes the way any ordinary JVM would -- it is just
that we happen to find the method bodies in an unusual way.  Most of
the details at the SecurityManager level of abstraction won't be
gcj-specific at all.


Here is my current security-related task list:

* Audit the library for missing calls to SecurityManager, and fix
  missing parts of SecurityManager.  I know there are some, e.g. look
  in natClass.cc for the "security" FIXME, or search
  SecurityManager.java for "XXX".

  The very best thing here would be to add Mauve checks to test every
  single required call to SecurityManager, by reading through the
  class library reference and writing the tests.  Then we could be
  fairly sure that we have caught them all and that we won't
  accidentally delete one.

* Likewise, audit the library to make sure all calls that end up in
  native code are checked.  I think at the moment it is possible to
  open a file and do nasty things by using gnu.* classes directly.

  Again, a test suite here would be excellent.  Actually, I would say
  it is required -- the point being that we don't want to have to
  re-do a complete audit again.

* Finish java.security.AccessController.  There was a patch in this
  area but it got dropped :-(.  I think the corresponding PR
  explains why.

* Correctly generate StackOverflowError

* Audit the class loading and verification code to make sure all
  required constraints are actually tested.  I suspect some are not,
  e.g. whether we use invokestatic on a non-static method, or class
  file version numbers.

  We have a few Mauve tests in the 'verify' module for this.  We need
  many more.

* Finally, audit the native code itself for security gotchas: buffer
  overflows and whatever else.

See also PR 13603, the security tracking PR.  I suppose I should file
PRs for the other parts.

Tom