> On 21 May 2021, at 12:52, Peter Firmstone <peter.firmst...@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
