Replacement of sun.reflect.Reflection#getCallerClass
nicholas+openjdk at nicholaswilliams.net
Tue Sep 3 14:44:53 UTC 2013
On Sep 3, 2013, at 9: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.
> 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. 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.
> 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.
Yes. Exactly. Thank you.
>>> And, has been stated many, many times, this non-goal is incompatible
>>> with the community's needs. Now, there /is/ a way to avoid making
>>> @CallerSensitive public (which the community doesn't care about) while
>>> still making getCallerClass public (which is really what the community
>>> needs). In order to do so, you must remove the check that requires the
>>> method calling getCallerClass/getCallerFrame to be annotated with
>>> @CallerSensitive. Once you remove that check, you don't need
>>> @CallerSensitive to be public. To be clear, though, once you remove
>>> that check, you don't need @CallerSensitive /at all/. It can simply go
>> Do you mean sun.reflect.CallerSensitive can go away? This is very
>> important part of the design that we need to detect which methods are
>> caller-sensitive. I keep seeing you suggest this and it is unclear to
>> me if you only mean to remove java.lang. at CallerSensitive in your proposal.
> - DML
More information about the core-libs-dev