[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cp-patches] RE: RFC: gnu.classpath.SystemProperties

From: Mark Wielaard
Subject: [cp-patches] RE: RFC: gnu.classpath.SystemProperties
Date: Tue, 07 Dec 2004 08:33:44 +0100


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:
This was also one of the comments of Archie Cobbs on your first design:

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:

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



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]