gcj-security and some issues

[Michael Koch]

Am Dienstag, 27. April 2004 00:19 schrieb Jakob Praher:
> 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?

Yeah, you just described our general plan. Unfortunately this security 
is not so easy to implement. Otherwise it would be done already. I 
looked into all this lately and stopped soon because somethings are 
missing that is being worked on by others. We need better stack tracing 
support to implement AccessController for real. Currently this is more 
or less a stub implementation. When AccessController is complete we can 
start with the CodeSource stuff. Otherwise it makes no sense (at least 
to me).


Michael