JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Alan Bateman]

On 23/07/2021 11:48, Peter Firmstone wrote:
>
> Perhaps the solution is to replace the entire class, instead of 
> instrumenting one method?
>
> Compile a patched copy of the JVM, with modified class files, then 
> replace the existing classes in the JVM with the modified classes?
>
> Kinda like maintaining a fork, but using Agents to instrument the 
> original JVM with classes from the fork?
>
> I sure wish there was a better option, if anyone knows one, I'm all ears.

JEP 411 puts the JDK on the road to dropping support for sandboxing. 
This means there won't be a built-in means to securely run code that has 
malicious intent. It means that many of the concerns for finalizer 
attacks go away too. In the case of the ClassLoader example in your 
first mail then it may be that the private static method that you want 
to instrument will be removed. If removed, then it should make the 
instrumentation a bit easier so that you can instrument the protected 
constructors to invokestatic your equivalent of a permission check 
before the invokespecial. So I think this specific case is surmountable 
but in general I don't think it will be tenable to patch hundreds of 
classes and be confident that you've got everything, esp. with a moving 
code base and new features. I can't tell if your "authorization layer" 
is for use when running with code that has malicious intent. If it is, 
then I don't think it will be tenable to duplicate all the deeply 
invasive permission checks that exist today and keep it up to date as 
new features and changes. When agents were muted in the early discussion 
on JEP 411 then the context was file and network access where several 
people were interested in having a means to veto access. Expanding this 
to have a SM equivalent be able to veto every reflective access, prevent 
trusted method chain and other attacks, amounts to keeping the SM forever.

As regards the comments about agents having the power to instrument 
methods that aren't accessible to user code then that is normal. Java 
agents are for tools to do powerful things, they aren't intended for 
libraries for applications to use directly. This is why agents are 
opt-in on the command line. Agent maintainers weld great power and must 
take care to never leak the Instrumentation object to applications or 
libraries.

-Alan