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

[Ron Pressler]

> On 21 May 2021, at 12:52, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> 
> It's quite clear this will be pushed through anyway,
> 

No, not *anyway*, but given the fact that the community consists of millions of users, this
proposal has been well-publicised, only very few people have voiced objections, fewer
still who have voiced objections actually use the Security Manager for security, and no
one has yet made a single relevant argument, accepting this proposal so far seems like the
only reasonable outcome, perhaps with accommodations to offer alternatives for certain
use-cases. 

> so there's no harm in sharing the information, unless you don't have a list, in which case it's not possible to share something you don't have.

I have already linked to one empirical study, I know that further scans of public repositories
have been conducted but *I* don’t have the data; those who do are free to share it if they
think there is no harm in that (although I think there might be).

> 
> The granularity is not arbitrary, you said by class, which is incorrect.
> 
> Granularity is by a combination of one or more of the following:
> 
> 	• ProtectionDomain
> 	• CodeSource
> 	• Code signers
> 	• ClassLoader
> 	• Principals.

What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method 
(certainly not in code you can’t modify). In fact, ProtectionDomain is defined as “a set of classes,”
i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged 
aims to address, and that is one of the Security Manager’s most defining features.

Restricting access by principal at the application level does not require the Security Manager, so that 
part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and 
ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.

> 
> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.

The pain is that the high cost of maintaining the Security Manager comes at the expense of
other security measures that, we believe, provide far more security value to the Java ecosystem
as a whole.

> 
> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.

I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
of applying it at class granularity yields its best application.

> 
> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.

There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for 
specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their 
expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the 
module system’s defences -- and we believe investing in them has a better security ROI overall.

> 
> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.

First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why 
we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
don’t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five 
years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms 
have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.

> 
> Currently it is the only possible and practicable means that has been implemented, I'm sure something better will come along, but everything better is just theoretical at this time.
> 
> Nothing else is even remotely capable of locking the JVM down this securely.

I‘m sure you're responding to *some* argument, but not to mine. Any additional security measure would 
“lock something down” more than not having it. Whether or not it is worthwhile depends on the marginal 
benefit vs. the marginal cost. I believe that the marginal benefit for the marginal cost of the Security 
Manager with respect to the existing measures I listed above (and which are constantly improved) is low, 
lower still considering how rarely it is actually employed in the field.

If we could invest as much as we want in those mechanisms and *also* have the Security Manager for those
few who use it for additional security, however small, we would; but we can’t. For a given investment,
the other mechanisms protect the Java ecosystem overall better than the Security Manager.

> This is not new software, these justifications are for new features, and would have been originally considered, now it has become a backward compatibility and functionality issue, no replacement functionality is available.

No, they are not. They specifically concern the *current* value of the Security Manager rather than
some future value. And while there is no replacement *to that particular security model* — because
we believe, like other platforms, that it fundamentally offers a bad ROI, not only are there alternative
measures to securing Java applications, but most applications have been relying on them rather than on
the Security Manager for years.

> 
> I don't see how you can argue there are better ways if they don't exist.

They do; I listed some of them.

> 
> This is a breaking change to Java, so after this JEP, you should be releasing Java 2.0.

It absolutely is a breaking change, but it is hardly the first, nor is it even the biggest (that
would be, I think, the removal of Applets). This isn’t even the only “breaking" JEP proposed to target 17.

We make intentional breaking changes when the number of those affected is small, and when the cost of 
maintaining a feature far outweighs the value it brings to the ecosystem as a whole. When we do, there 
is always some non-zero number of people who are harmed, but because such features incur a constant cost 
that comes at the expense of other things, we don’t remove unless we think more people would be harmed by 
keeping the feature.

We recognised some years ago that *sometimes* the most appropriate course of action, the one that yields the 
greater good for the greater number, all things considered, is to make breaking changes. Not making intentional
breaking changes ever might have been a viable strategy in Java’s first decade or so, but as time passes and
obsolete/abandoned/disused features accumulate, it no longer is. Still, we do our best to minimise the harm.

I saw that you’ve come to the conclusion that the best course of action for you would be to invest
in maintaining old Java versions. I would just like to suggest that you stay open to other possibilities
of providing good security without the Security Manager, as you might find cheaper options (consider that 
the small number of libraries instrumented for the Security Manager will diminish further once it is removed, 
so you’ll have more than just the JDK to maintain, and even that is a large undertaking). As I already 
mentioned before, think of suggestions you could make that might be acceptable and would reduce the impact to 
you. I think you’ve already made one.

— Ron