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

[Peter Firmstone]

I think it's worth noting that there isn't a way to securely run code 
with malicious intent now, so I'm surprised that at this late stage you 
were still providing support for sand boxing (whack a mole).

It's just for us many assumptions have been made on a Java platform with 
SM, using POLP (not sandboxing) as this was one of the foundational 
principles of secure coding guidelines (just like following concurrency 
best practice, were were following security best practice).   Sandboxing 
is an all or nothing approach, if you had a trusted applet that was 
signed, it had AllPermission, if you had an unsigned applet, then it had 
no permissions.  Sandboxing was one of the use cases for SM, when 
combined with ClassLoader visibility, but we never realized that OpenJDK 
developers meant sandboxing == authorization access controls.

When you remove that pillar, everything it's supporting collapses, not 
just sand boxing, so when you say you are removing support for 
sandboxing, we say, good idea, but we didn't realize you were saying you 
were removing support for all authorization access controls.   Reduced 
and revised authorization and access control would have been acceptable, 
as tightening reflection visibility using a different form of access 
control removes the need for authorization based reflection access 
checks, but also removing atomic construction guarantee's just seems 
like were doing this at a rapid pace without the community understanding 
what you have in mind, and this may have more uses than just stopping 
finalizer attacks.  Unfortunately when you develop a feature, you can't 
be sure developers won't adapt and utilize it for multiple purposes.

Personally I think a better approach would have been to first reduce and 
simplify authorization access controls, replacing some of the 
functionality with different but more appropriate mechanisms.

Removing authorization access control features, without replacement 
means our software would be insecure, there isn't an obvious way to 
re-secure it, without re-architecting or re-designing it from the ground 
up, and Java is now a moving target anyway, so we would have to wait for 
it to re-stabilize as it transitions from Hippy to Hipster Java (just 
making a point it's not the same Java).

With this new understanding, we need to reconsider both the language and 
the platform that we'll be developing on.  Clearly a language with less 
boilerplate is an obvious start, I don't yet know which, we will still 
consider the JVM, but it would be with Kafka or Clojure, but then we 
also need to consider whether we will be able to secure the underlying 
platform, or at least use it securely.  Arguably we can do things now 
that aren't possible on other platforms, so we need to develop that 
capability as well, not just secure it.

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