gcj-security and some issues

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