Security in libgcj

Tue Mar 22 18:07:00 GMT 2005

>>>>> "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