On 09/03/2013 10:17 AM, Jochen Theodorou wrote:
Am 03.09.2013 05:04, schrieb Mandy Chung:
Hi Nick,
Thanks for the patch.
JEP 176 [1] describes the caller-sensitive method and the need for a
mechanical checking of caller-sensitive methods. Also Peter Levart in
[2] explained the change in MethodHandles.Lookup related to @CS. I
assume you understand the rationale behind and the potential security
issues. In general defining caller-sensitive API is discouraged.
The problem is, and the JDK itself shows that, that you sometimes
cannot avoid caller-sensitive API. I thought that was clear by now. I
am not the patch author, so understanding the potential security
issues was not addressed to me, but I would like to understand them.
So far I did hear only that if you have the Class object, you can do
something, you normally cannot do. I would be interested in an
example. Java security is really complicated to understand, and this
would help to shed some light on the issue for others. Also I am
wondering, if the Class object is a no-go, then how about class name
and class loader? For Groovy we need the loader, but since we need to
filter stack elements ourselves too, we also need the class names. A
Class-object provides both, but I am sure almost all usages out there
could work with the name and the loader only and if needed loading the
class from the loader, with permissions set accordingly. Not sure how
it is with internal class names here of course. AnonymousClassLoader
would probably cause trouble here, but afaik that did not make it out
of JSR292.
A different way to solve the issue was suggested as using an
annotation to define frames which are not looked up by getCallerClass.
But it did not get any interest. So I am really curious how you want
to solve this.
I think there are two different things, first, there are several methods
in the JDK that allows operations or not (like calling a method by
example) based on the caller class. So if you can impersonate the caller
class, you can do privilege escalation.
The fact that the method that does a security check based on the caller
class (or the caller stack trace) has to be tagged using @CallerSensitive
for the method handle API is an implementation detail. The current
implementation of the method handle API invocation in Hotspot may used
intermediary stack frame between the method call do a
methodHandle.invoke/invokeEaxct and the actual called method. If the
actual method do a security check using the caller class, it may see an
intermediary method and not the original caller method so if you are not
able to detect the caller sensitive method, you can use the method
handle API to do privilege escalation. That's why in the JDK, methods
that are caller sensitive are marked with the annotation
@CallerSensitive. Again, this is an implementation issue specific to the
way the method handles are implemented, so that's why @CallerSensitive
is defined in package sun.invoke and not in a public API.
Now, correct me if I'm wrong, for Groovy, you need to get the groovy
caller method, (it can be a Java method because you can implement a
callback in Groovy and send it to a Java code) so you should not use
getCallerClass which should be reserved for security checks but another
method that will return the caller method (or caller methods) that will
filter out and the intermediary methods due to the method handle
implementation and the intermediary methods due to the Groovy runtime
(those can be marked with an annotations).
So there is a need for an API to get the caller classes which is not
getCallerClass (or any methods in a package sun.*) that will hide you
the method handle API impementation and allow you choose to filter
caller methods using a user defined API.
[...]
bye Jochen
cheers,
Rémi
