[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[Tom Hawtin]

On 02/09/2013 09:33, Alan Bateman wrote:

>  From a quick scan then it appears that you've decided to ignore the
> security concerns so I don't think anyone can (or should) sponsor this
> patch until there is further discussion on the API and the security
> implications.

I've barely looked through the patch, let alone audited it. However:

As the method appears to be mostly for tracing, performing a security 
check per invocation is likely to hurt performance. Unless it was caller 
sensitive (which seems to be equated with Bad Practice these days) it 
would also require a doPrivileged block. Much better to perform a single 
security check when acquiring a capability object, in a similar(ish) way 
to sun.misc.Unsafe or SharedSecrets.

In order to work with less privileged code, it may also be worthwhile to 
provide a version of the capability object parameterised with a class 
loader. If code has access to a ClassLoader object, then it is 
consistent for it to be given access to Classes loaded by it or child 
loaders, and in practice from parent loaders (but not children of parents).

Security relating to Class objects is "interesting". The genuine 
security issue with Class objects is that they have are an attenuation 
of the capability of their ClassLoader. There are many ways to acquire 
Class objects. Some have confusing defence-in-depth security; some, such 
as Object.getClass used for quick null checks, do not.

Tom