Replacement of sun.reflect.Reflection#getCallerClass

[Mandy Chung]

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.
>