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

[Peter Firmstone]

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.

Regards,

Peter.

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 
>> 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