JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

I'm potentially watching many years of development efforts burn, due to 
JEP 411 and trying to find a way to save it, I don't refer to it as 
fun.  Frustrating, infuriating, irritating, anger, that would more 
accurately describe the emotions current circumstances create.

I'll be focusing only on the following in Java's public API's:

 1. Network.
 2. File system access.
 3. ClassLoading.
 4. Properties.

The most important task is to prevent class loading from unauthenticated 
sources.

This is intended to sure up perimeter defenses and constrain trusted 
third parties in our software, these would be wide open if we just 
switched off SM.

I'm following all guidance provided by OpenJDK in this instance.

I will wait for finalizers to be removed, before instrumenting any 
constructors that have finalizer attack defenses.  Hopefully OpenJDK 
will chose to remove finalizers soon, prior to removal of SM.

Regards,

Peter.



On 31/07/2021 5:35 pm, Alan Bateman wrote:
> On 31/07/2021 04:04, Peter Firmstone wrote:
>>
>> Allan has advised when finalizers are removed, it will be practical 
>> to use Agents to instrument public API to implement an authorization 
>> layer, this is try, so can it be coordinated with JEP 411 et al?
>>
> Our exchange was about instrumenting constructors that specify SM 
> permission checks and where the classes that define these constructors 
> have been hardened to thwart finalizer attacks. It wasn't a comment on 
> the bigger question on how practical it is to use instrumented the 
> entire JDK. Once you get further on then I assume a big challenge will 
> be with APIs that separate the interface and implementation (think 
> factory methods, APIs that define service provider interfaces ...). 
> Here I expect you will want to instrument the implementation classes. 
> Going deeper, you may find places where the SM check isn't on method 
> entry but instead after defensive copying of mutable parameters or 
> after acquiring a lock that prevents mutation while do a security 
> sensitive operations. So non-trivial but a fun approach to explore. If 
> you have the cycles then pick a version and try it. That will give you 
> a sense on how much effort may be required to keep up and be confident 
> that every interesting code path is covered.
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210731/8773e128/attachment.htm>