[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

On 18/05/2021 10:21 am, Ron Pressler wrote:
>> On 18 May 2021, at 01:11, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>> Your ideas are great in theory, in practice, the problem with your Agent proposal is every JVM release needs to be reviewed, and we have to review Java's internal implementation code, and understand it in order to instrument it.
> Absolutely. But that is exactly the work OpenJDK maintainers are required to do today to support something most
> people want better alternatives for at the expense of those better alternatives and other work.
>

The Principle of Least Privilege reduces the consequences resulting from 
attacks that penetrate external security defenses, whether by social 
engineering, failure to sanitize input, protocols, or platform 
vulnerabilities.


After many years of pain, JDK development work has not been wasted, I 
for one am grateful for the development efforts and thoughts put into 
securing the JVM.   It is expensive and now your employer has decided 
they no longer wish to carry this expense, pushing it downstream.

Java has a proven and well tested security API, it's flaws are generally 
well understood.

At sometime in the future, Java's internal security defenses will be 
removed, and new code will no longer perform permission checks, so any 
breaches of external defenses will result in a JVM being Pwned.

After considering the proposals for new Security API, I have decided 
that the Java 1.8 to Java 1.17 versions will be the most suitable as it 
has the best well developed and understood security architecture, 
requiring little further development work.

The new proposals arising from this JEP present a significant 
development upgrade cost, and these new API's that we need to use for 
building new security architecture around, won't be battle hardened, are 
experimental and haven't passed the test of time.

My assessment is the cost to upgrade is too high and far too great a 
risk in this instance, the least cost and safest option is to stay with 
well proven, deployment tested, high performance, hardened existing API's.

I wish the OpenJDK project success in their future endeavors.  We will 
try to support later Java versions in Service implementations, similar 
to other languages, however these will not be able to consume other 
services.  This may enable users to take advantage of later language 
features.  However we will always require the use of Java 1.8 to 1.17 as 
service consumers.

I am grateful for the efforts, which appear to be thought of as wasted 
efforts or bad money, however this time spent addressing security 
issues, will leave the series of Java versions from 1.8 to 1.17 as some 
of the most secure versions of any software platform, as an asset of 
significant value to those who value security.

Thank you.

Peter Firmstone.