gcj-security and some issues

Jakob Praher jpraher@yahoo.de
Wed Apr 28 20:34:00 GMT 2004

Am Mit, den 28.04.2004 schrieb Tom Tromey um 18:26:
> >>>>> "Anthony" == Anthony Green <green@redhat.com> writes:
> Anthony> If we're primarily interested in identifying protection
> Anthony> domains, are there some short cuts we can make?  For
> Anthony> instance, can we just map .so's to protection domains, and
> Anthony> then simply identify which .so a PC is associated with
> Anthony> (rather than go all they way down to the class level).

Interesting. I could imagine treating this special Classes inside GCJ
different would surely drastically improve performance. Performing the
security checks very efficient is very important. I think the number of
ProtectionDomains (at least when thinking about it) is roughly the
number of entries of grants in the policy file. So this is not as high
and perhaps could be even stored as some few bit bitmap in the class
header. But I don't know whether thats a good idea. (Perhaps to

What worries me more, though is how to make a distinction between code
that comes from java sources and code that comes from c/c++/asm. The
only party that knows that is the compiler. It would be interesting  if
the compiler could put the start and the end adress (pc) (perhaps
relative adress, for relocation and so on) of the methods that were
written in java in a write protected memory area (in the constant
region). The reflection system could then safely determine whether this
code is faked or not, since even malicious c/c++/asm code can't get
arround the OS restrictions for that memory area, and can't add itself
into the address table. This calculation could even be fast, since it
would consist of a simple address comparition.
What do you think?

> Eventually we'll be able to load multiple .so's via different class
> loaders.  So the mapping would have to be by the particular mapping,
> not by, say, the .so's inode.

hmm interesting. So you mean by that, that one could override the
natClassLoader by some other shared object loader, or how shall I
understand that? How does that affect the CodeSource, I mean the
location doesn't change regardless which class loader is used.

> It should be pretty easy to set the protection domain on classes
> loaded from shared libraries.  I had started a patch to do this
> (according to my notes, late 2002) but never quite finished.  I've
> appended it in case it is useful to someone.  ISTR it was really
> inefficient, there's probably a better way.

thanks for the patch, it is quite interesting to read :-). Some
questions, at least to get more understanding on gcjs working:

setting the ProtectionDomain here is called from withtin the
_Jv_RunMain. Does this mean this gets only done for a executable/shared
object, that calls the RunMain function.

I mean how is the following scenario handeld in the current gcj?

if you have 1 executable and 2 so_s:
main, foo.so, bar.so
main   contains : Main class (calls the Jv_RunMain method)
foo.so contains : Foo class
bar.so contains : Bar class

for instance Main looks like:

int main( String[] args ) {
   Foo f = new Foo( );
   f.doIt( );

class Foo {
  public void doIt( ) {
     new Bar( );

as javas dynamic nature, java does lazy initializing/loading of classes.
What hapens when Foo is needed, but is not registered in the executable
main yet (are the class objects registered by the function
_Jv_RegisterClasses ?)
The shared object will get loaded by natClassLoader.cc defineClass, so
this should get updated too (at the end of the patch this file is also
mentioned, but not mutch more). 

What is the job of the initiated_classes array. Does it contain all
classes that are loaded and usable?

Btw: What does 
	_Jv_ThisExecutable ();
return for shared objects ?

-- Jakob

More information about the Java mailing list