This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcj-security and some issues


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]