[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Moving system properties to gnu.classpath.*
From: |
David Holmes |
Subject: |
RE: Moving system properties to gnu.classpath.* |
Date: |
Tue, 12 Oct 2004 08:37:19 +1000 |
Jeroen,
> Yeah, the documentation sucks, but how is this any different from any of
> the other APIs ;-)
This seems to be a fairly critical part of the classloader security
architecture that is simply not documented. This makes it rather difficult
to know how it is supposed to be implemented.
> It isn't trivial without creating your own class loader (which is a
> privileged operation).
True, but the createClassloader permission is not supposed to imply
accessPackage.* permission, but that is what could occur. This might be a
small crack inside the vault but it is still a crack that should not be
there. Much of the security architecture talks about malicious classloaders,
but you are implying that all classloaders are trustworthy.
> If you read the security bulletin I pointed to,
> you'll see that Sun relies on this same mechanism to prevent access to
> the sun.* package, so presumably it is intended to be secure.
Presumably that is the intent. But then it depends on how you actually put
this security check in place. How can I say this without "tainting" you? -
Sun does not do this according to the letter of the method documentation.
> > The only way this check could work reliably is if the VM
> > itself performs the check. But it seems to me that this is a very
> > underspecified part of the security architecture - other than when
> > invoked via the reflection method.
> > Curiously I've been unable to find any information as to when
> > checkPackageAccess should actually be invoked!
>
> I hope you're not arguing that we shouldn't implement it, just because
> it is underspecified?
Of course not. Classpath should be implementing this regardless - it is part
of the security architecture. The problem is that we don't know exactly how
to implement it - ie where should the check take place. And it is my opinion
that the check would need to be done by the VM so that a malicious
classloader could not circumvent it.
I'm still quite surprised that I can find so little information about this
aspect of the security architecture. I'm tempted to file a Sun bug report
against Classloader.loadclass to request that it documents how the security
check is to take place.
David
- Re: Moving system properties to gnu.classpath.*, (continued)
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/08
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/11
- RE: Moving system properties to gnu.classpath.*,
David Holmes <=
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/11
- RE: Moving system properties to gnu.classpath.*, David Holmes, 2004/10/11
- Re: Moving system properties to gnu.classpath.*, Archie Cobbs, 2004/10/12
RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/11
RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/12
RE: Moving system properties to gnu.classpath.*, Jeroen Frijters, 2004/10/12