question about security impl

Fri Mar 19 07:47:00 GMT 2004

>>>>> "Jakob" == Jakob Praher <jpraher@yahoo.de> writes:

Jakob> AccessControlContext acc = AccessController.getContext( );
Jakob> Actualy the current source implements this as:
Jakob> new AccessControlContext( new ProtectionDomain[ 0 ] );
Jakob> I would like to discuss how this could be implemented (or maybe I am
Jakob> missing something). 
Yeah, look at the "XXX" comments in this code. Basically it is
unfinished, it needs someone to research the problem and figure out
what to do.
As far as examining the call chain, see gnu.gcj.runtime.StackTrace.
We probably have all the needed low-level machinery to implement this
stuff correctly. If we don't, well, we need to find that out and
figure out what we do need.
See our security tracking PR and its dependencies:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13603
This is a holder that just points to all the other PRs related to
features that we know are missing and that must be implemented before
we can claim to implement the Java sandbox.
I think Bryce was working on 12740 and perhaps 11780 -- I know he had
some major StackTrace changes in the works.
Jakob> * CodeSoure path differences between jar/directory locations and shared
Jakob> object files
I don't understand this one...
Jakob> * Is there a way to do this safely in gcj? Maybe one could simply not
Jakob> allow foreign unsigned code to contain native compiled code per default.
Jakob> So that translation to native code takes place at a "safe" place.
Right now this stuff is a bit problematic.
With the binary compatibility ABI, the gcj-jit idea, and another thing
Andrew is working on (the ability to compile a .class file in
isolation without requiring other classes to be available to the
compiler), we'll be able to compile and dlopen untrusted code without
security worries. See PR 13606 for the verification part of the
puzzle. Andrew might be working on this, I'm not sure. And anyway it
interacts with other verifier plans, see the thread from yesterday.
Jakob> * sealing shared objects? this should be hard to do since its a trust
Jakob> problem (but I think we can't verify/check native code in a timely
Jakob> manner)
I don't know about this one either. Can you explain it? Do we need
a new security-related PR for it?
Jakob> I look forward to discussing these things with you.
Jakob> (I am an gcj-apprentice and glad when learning something new about the
Jakob> impl). 
We're definitely interested in having help in this area. Nobody is
actively hacking on most of the parts of it, but we know we definitely
want it to be done. In particular gcjwebplugin is going to need this.
Other useful tasks are: go through all the code and make sure we call
into SecurityManager everywhere we are supposed to, look at other
potential ways to circumvent security checking (e.g., whether there
are unsafe gnu.* classes), and last but not least write test cases for
everything imaginable -- there are one or two security tests in Mauve
right now, I'd like to see hundreds.
Tom