gcj-security and some issues

Jakob Praher jpraher@yahoo.de
Mon Apr 26 22:19:00 GMT 2004


hi all,

today I played a little bit with the current (cvs-head) implementaiton
of gcj and the security model.

fortunately I found some of the things like
* ProtectionDomain
* CodeSource
* Permission

are already there.

The gratest problem I'am facing now is, getting to know gcj internals 
better. I found the --save-temps option useful, but not terrific.
Objdump -d on the other hand showed a more complete picture, but only
includes local method call names. ltrace showed a funny picture:

_Jv_RegisterClasses( ... )
__libc_start_main( ... )
_Jv_RegisterClasses( ... )
JvRunMain( ... )


* Obviously the _Jv_RunMain sets up the system. It calls
_Jv_CreateJavaVM. But which routines call the _Jv_RegisterClasses, since
the _Jv_CreateJavaVM already assumes a setuped jclass. 

* why is the call from __libc_start_main between 2 _Jv_RegisterClasses
invocations?


My current observation:

In current gcj executables every class loaded (in java jargon) from the
system loader (classpath in interpreters), has a ProtectionDomain with a
CodeSource of null. According to my book (J2SE Security) and to a
testcase I've written, system loaded classes' CodeSource should be the
location of the class file.

I think it would be better to actually point the CodeSource to the
location of the native executable/shared object, since this is where
this instance is comming from. Because compilation may happen on another
machine the location of the original jar/class/java file is not an
option here. (gij is another thing)

This would at least enable an admin, to specifiy the location of the
shared object/executable as the codebase of the policy grant. 
For instance

an application loaded from:
/home/x/bin/MyApp

could get different permissions than
/usr/bin/MyApp

and so on.

I was wondering whether it would be possible to track whether a
executing method comes from a java source or from a native source
(natXX.cc). I could imagine the compiler could support this, since it
knows whether a Method is defined using Foo.java or natFoo.cc. To keep
the system secure, this information should be write protected, (though I
have not much experience in doing that), since this would prevent
"malicious" native code from changing its origin to java etc.
Any thoughts here?


-- Jakob






More information about the Java mailing list