RE: RFC: gnu.classpath.SystemProperties

[Mark Wielaard]

Hi,

On Mon, 2004-12-06 at 22:10, Jeroen Frijters wrote:
> Mark Wielaard wrote:
> > Could you describe how this precisely works?
> 
> All untrusted classes are loaded by the system class loader (or some
> other trusted class loader that will be responsible for calling
> SecurityManager.checkPackageAccess()). If an untrusted class refers to a
> class in one of the gnu.* packages, the VM will attempt to load the
> class through the defining class loader of the untrusted class (e.g. the
> system class loader) and that class loader will make sure that the class
> won't be able to load those restricted classes.

OK. Thanks. Read up on the threads were you describe the system
classloader changes needed. I had forgotten that you already did all the
work needed here. Sorry.

So the only thing a execution environment has to do to make this work is
to properly resolve all Class references through ClassLoader.loadClass()
which it already should do. It might be nice to add a little example of
a program that shouldn't work anymore in the new system when a security
manager is installed so runtime implementers can check this.

I had some more discussion on irc about it and Dalibor was quick to
point out that there might be a security issue in the way we do this:
http://addict3d.org/index.php?page=viewarticle&type=security&ID=124
This was also one of the comments of Archie Cobbs on your first design:
http://lists.gnu.org/archive/html/classpath-patches/2004-10/msg00073.html

It seems we need to be very strict in only accepting the dot notation
everywhere (although I seem to remember that the slash notation is
accepted in a couple of places).

The above also lead me to this security paper which might be interesting
to go through to create a mauve security module to check our library and
runtimes against: http://lsd-pl.net/java_security.html

All this painfully points out how fragile the security mechanism is in
the face of user defined ClassLoaders. After reading the above I am not
so sure the way some applications overload ClassLoader.loadClass() is
done correctly (unfortunately this seems a common technique in the J2EE
world).

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part