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

[Alan Bateman]

On 23/07/2021 23:33, Peter Firmstone wrote:
> 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. 
I'm not 100% sure what you mean by "atomic construction guarantee" here. 
This JEP does not propose to change anything with finalization or do 
anything with the registration of finalizers after Object.<init> runs. 
Our exchange in the previous mails was about classes (using ClassLoader 
as the example) that specify a SM permission check in their 
constructors, something that is strongly discouraged as the checks are 
easy to bypass. The idiom that we use in the JDK to prevent bypassing 
these SM permission checks with a finalizer attack is to check in a 
static method that returns a dummy parameter for the invokespecial. My 
point in the previous mail is that when the SM permission checks 
eventually go away then many of the uses of this idiom can do away too.

That said, there is strong desire to eventually remove finalization too. 
Finalization was deprecated several years ago and the Java platform 
defines APIs that provide much more flexible and efficient ways do run 
cleanup actions when an object becomes unreachable. So another 
multi-year/multi-release effort to remove a problematic feature, just 
nothing to do with this JEP.

As regards POLP, the focus of SM architecture when it was enhanced in 
Java 1.2. The JEP attempts to explain why this has been a failure. 
AccessController is voodoo that most developers have never encountered 
so anyone trying to run with SM ends up running counter to the principle 
of least privilege by granting all permissions.

-Alan.