JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.
Alan Bateman
Alan.Bateman at oracle.com
Fri Jul 23 11:45:32 UTC 2021
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
More information about the security-dev
mailing list