On 9/3/13 7:40 AM, David M. Lloyd wrote:
On 09/03/2013 09:30 AM, Mandy Chung wrote:
On 9/3/2013 5:52 AM, Nick Williams wrote:
Do, I don't understand the rationale. Alan said the security issues
couldn't be discussed openly. I can get a Class object MANY different
ways without a security check. I don't see or understand any
vulnerabilities here. I'm going to need much more information in order
to contribute to the discussion in an informed manner.
The Java security guideline is a good starting point.
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#4
Spelling this out for clarity. This document talks about using access
modifiers to restrict class definitions, which I think everyone agrees
is a reasonable security measure.
I didn't mean to refer specifically to section 4 (sorry for the
incorrect URL - cut and paste issue) but instead the entire Java
security guideline. Section 9 contains the information relevant to the
immediate caller.
It specifically does *not* address accessing java.lang.Class
instances, which are not protected or guarded in any way as far as I
can see, and are as easy to access as .getClass() on any Object
instance. In other words, if you have an object, you have its Class
instance as well.
That's one problem - you don't always get a hold of an object of any
sun.* classes for example. However, walking the stack will mean that
you now can access to a sun.* Class even if you don't have access to any
instance. I'm not making any conclusion whether we can or can't provide
such API but just to point out that the security issue requires detailed
thought-through.
Mandy
The document *does* cover the (existing) protection of requiring a
runtime permission to access the class loader from a Class (or other
ways).
Again, the doc talks about protecting ClassLoader instances, *not*
Class instances. If accessing Class instances is a security hole,
then we already have a serious problem that has nothing to do with this.
