JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.
peter.firmstone at zeus.net.au
Fri Jul 23 12:35:36 UTC 2021
Trusted code only, but it's intended to be run in a locked down
principle of least privilege environment, while we perform static
analysis and targeted review, we don't have the resources required to
perform thorough trusted code audits, so have been reliant on the
principle of least privilege. Hence the ability to generate policy
files that we use for auditing.
I utilize the constructor guarantee added in Java 6, that prevents
finalizer attacks for atomic de-serialization, if invariants aren't
satisfied, failure is atomic, thanks to this feature.
We use the SM to ensure network connections used are secure and only
have authenticated users, otherwise de-serialization and dynamic class
loading is prevented.
We don't need all the SM permission check features, but preventing
unauthorized class loading is one of them. Network, file access, class
loading, properties are a few that come to mind, I'm not worried about
reflection, other recent changes are taking care of reflective access.
We have a heap of our own Permission implementations as well.
It appears that Java's future path is diverging from our software's
needs and Java won't be a suitable platform in future. I wasn't aware
that Java was heading in this direction. JEP 411 came as a big
surprise, it just seemed like it was a core Java feature.
I think the best course of action, will be to focus on Java 8, until
that's EOL'd. I do like the improvements to TLS stateless connections
and new features in later Java versions, but it looks like a mistake to
try and keep up with Java, with this new knowledge. I think I'll back
out some more recent changes that were intended to allow our software to
run on Java 17, as these cause breakages for downstream developers and
it doesn't seem to make much sense now, to make those breaking changes.
I was actually looking forward to taking advantage of loom and the new
vector API, but it looks like I need to be focused on what's going to be
our next software platform. I've always found llvm to be interesting,
so maybe I'll focus on some languages that run on that, and implement
privileged constraints at a lower level.
Perhaps by the time Java 8's EOL'd there will be a new platform and
language that's more suitable.
Thank you for your time, I do appreciate your replies and it gives me
the clarity I needed.
I wish it wasn't the case, but I have to accept that times are changing.
Best of luck for the future my Java friends, it's been a powerful
language, especially with regard to concurrency and scaling, we got
great performance, all our hotspots were native methods and Java let us
get close to the metal at low levels as well using bit shift operations
on primitives, that are magnitudes faster than standard string
operations. TLS ran so much faster with stateless session tickets too.
On 23/07/2021 9:45 pm, Alan Bateman wrote:
> 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
> 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.
More information about the jdk-dev