gcj-security and some issues

Wed Apr 28 22:54:00 GMT 2004

Jakob Praher wrote:
>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
>smalltalkish)
>>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. 
>
I think malicious native code is beyond the scope of the Java security 
model. OS-level security is needed to protect against such things - so 
we're getting into the domain of things like SELinux.
IMO the security model is needed in libgcj to support:
- Untrusted bytecode (interpreted, JITted, etc)
- Native code generated from untrusted bytecode in a trusted compilation 
environment.
>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 compiler already does this, as part of the DWARF2 unwind info. The 
tricky part is mapping the function to the class it belongs to. 
Currently this is done with a hash table but possibly we can add 
something to the FDE (LDSA?) to make it more efficient.
I'm not sure if reducing the granularity of security checks from the 
class level to the .so level would help that much. The cost of unwinding 
each stack frame (using EH info) to obtain the IP probably far outweighs 
the cost of mapping the IP to a protection domain, regardless of whether 
its at the class or the shared library level.
>Btw: What does 
>	_Jv_ThisExecutable ();
>return for shared objects ?
>>
It returns the name of the binary, not the .so. If you run a main class 
in a .so using gij it returns gij, I think.
Regards
Bryce.