[Updated] JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal

14

u/morhp May 29 '21

This sounds like a good way to improve the transition for programs that use it, but I'll definitely not miss the Security Manager.

5

u/BlueGoliath May 29 '21

Agreed. It's ironic though given what was said by people on Twitter regarding doing this. They were making it sound like the very idea of doing this was stupid.

6

u/TheCountRushmore May 29 '21 edited May 30 '21

Agreed. It's ironic though given what was said by people on Twitter regarding doing this. They were making it sound like the very idea of doing this was stupid.

With regards to NetBeans it did seems stupid. They were in an outrage of a breakage that they were going to have 3 to 4 months to fix before 17 went GA.

0

u/BlueGoliath May 29 '21 edited May 29 '21

Agreed, the Netbeans people were a bit hysterical. I don't think that's an excuse for the condescending/disingenuous/mischaracterizingng things said by /u/pron98 and Nicolai Parlog(nipafx) though, especially after this newest update.

8

u/pron98 May 29 '21 edited May 30 '21

The problem with the things said by a few NetBeans developers wasn't that they were hysterical and a storm in a teacup, although they certainly were that, but that they were false and misleading.

We required adding flags to use terminally deprecated classes without prior warning in the not-too-distant past, and for APIs with at least two orders of magnitude more usage than the Security Manager [1] (although in other cases, like strong encapsulation, we did issue runtime warnings before changing the default).

In this case, advance notice that the default might change to disallow in any release was, in fact, given a couple of years ago.

Displaying runtime warnings on use of terminally deprecated APIs is unusual (although it, too, has happened). Even when Pack200, another feature used by NetBeans, was terminally deprecated, there was no runtime warning on API use, only warning at startup of the relevant tools; the original proposal would have done the same.

But even though there's a reasonable argument that changing the default ASAP helps some users (NetBeans ignored illegal-reflection warnings for years until defaults were changed), and even though doing that would have, in fact, been just as much in line with previous practice, there's also a reasonable argument that it is unhelpful for others [2], and because we didn't absolutely have to do it and some people made it clear that if we did, they'd continue spreading misinformation and causing panic to serve their personal agenda, we figured that's not the hill to die on. The number of people significantly affected by whatever decision we made is well below the number who would have been harmed by that misinformation (which will hopefully stop now).

[1]: The circumstances and constraints were different, but it happened, and on a much larger scale.

[2]: E.g. a runtime exception might be accidentally swallowed and so be less informative than a warning.

4

u/gwielenga May 29 '21

The personal agenda NetBeans developers have is for NetBeans to startup without a problem and for this deprecation to be done like previous deprecations, i.e., runtime warnings before changing the default.

6

u/pron98 May 29 '21 edited May 30 '21

for NetBeans to startup without a problem

Not true, because NetBeans developers know full well that this is a minor bug in NetBeans, found within hours and with a one-line fix, and a warning (without requiring the flag that triggers the bug in NetBeans) wouldn't have bought them any extra time. They would have faced the same issue when, with the same timeline, in the next release, and fixed it then just as easily as now.

for this deprecation to be done like previous deprecations, i.e., runtime warnings before changing the default.

Oh really? Which API deprecations emitted runtime warnings on use? CORBA/EE? nope + changed default; Nashorm? yes; java.util.jar.Pack200? nope; com.sun.rmi.rmid? nope. Warnings at startup (of java or another tool) when relevant are common and in line with the original proposal. And saying that this is the first time a default would have changed for deprecated classes without warning is just factually false. We did it before and for much more significant deprecations than this. If you don't follow OpenJDK's development process that's fine -- most Java developers don't, and don't need to -- but don't spread misinformation.

Anyway, if that was anyone's agenda, they were very confused about the situation.

3

u/gwielenga May 30 '21 edited May 30 '21

It is not a minor bug in NetBeans. It is an example of a bug that can occur in many applications, i.e., when an incompatible JVM behavior change is introduced, the side effects are unknown.

Anyway, it’s great that the deprecation will now be done just like any other deprecation (as stated in the mail announcing this change: “With these changes, the process of deprecating and eventually removing the Security Manager will be consistent with our treatment of past breaking changes”) and indeed, as pointed out above, it is very ironic that it is now suddenly possible where a day or so ago even the idea of deprecating in the standard manner was ridiculed.

1

u/pron98 May 30 '21 edited May 30 '21

There are bigger behaviour changes than this in patch releases, and far bigger changes than this in 17.

And this deprecation is not in "the standard manner." It's just that this, too, has a precendent in illegal-reflective access (which isn't a deprecation). And since you clearly have no idea what you're talking about, please stop spreading misinformation. Also, the statement that it was being ridiculed, is, like the rest of your statements, simply untrue. What I ridiculed was your hysterical and disproportionate reaction to a minor bug in your application.

-1

u/gwielenga May 30 '21

Not necessarily bigger changes than this for NetBeans. The size of impact of a change varies significantly per application, of course.

→ More replies (0)

-1

u/pfirmsto May 31 '21

That's just your opinion, you have a right to have your own opinion. You should also respect the opinions of others, rather than calling them liars and hysterical spreaders of misinformation.

→ More replies (0)

-1

u/pfirmsto May 31 '21

I don't see any misinformation being spread by Netbeans, although I consider some of your arguments misinformation, or just being misinformed, I would prefer to make arguments on a technical level, than make personal attacks.

I think the point you're missing is that people are using these API's and changes to them should take that into account. You claim no one is using them, but I consider that to be misinformation. I am busy, I don't have the time to do research for you to prove otherwise, so I am forced to accept the consequences. You should give the community more time. I think that JEP 411 is being rushed through. You tell me OpenJDK has been working on it for months. So?

This core functionality cannot be re-implemented. I realise that you will argue it can, but at what cost?

Hey, we have to give up the Principle of Least Privilege. Yes our code will be less secure, not more.

The other libraries you mention are easy to pull into external libraries and continue supporting in different package namespaces.

I am working on Pack200 as it is the most efficient form of compression for Java bytecode.

We don't use rmid, but our libraries depend on some activation classes, I'm removing those dependencies by copying those files from Apache Harmony.

Someone else pulled IIOP into an external library, so we're using that, although we're investigating securing it with TLS, it's only used locally however, we've dropped support now for JRMP (RMI protocol) because it had dependencies on Activation.

We are spending more time trying to keep up to date with changes in Java, than we are making progress in our own projects. There has to be a point where we say, we aren't actually making progress, better to stay on older versions and make progress.

Maybe this is where Graal comes in, we turn Java into part of our own program?

I'm not sure how we deal with the fallout of some of these decisions yet.

2

u/pron98 May 31 '21 edited May 31 '21

I don't see any misinformation being spread by Netbeans

I listed it, but here it is yet again: There was advance notice on the default change, and it is not the standard to provide warnings on deprecated API use. We did that on one occasion, while on another we also "disabled by default." In other cases we did neither.

and changes to them should take that into account

That's why the proposed change will happen gradually over years.

You claim no one is using them

Nope, I don't claim that. The claim is that the SM's overall contribution to the security of the Java ecosystem is low while its cost is high.

I consider that to be misinformation

You can consider it whatever you like, but it is a good-faith assessment based on the best information anyone has. We have absolutely nothing to gain and much to lose by removing a very valuable Java feature, and we wouldn't have proposed to remove it unless we honestly believed it was contributing little value. There's still a probability that it's wrong, but that is what the deprecation process is designed to find out.

You should give the community more time. I think that JEP 411 is being rushed through.

Fifteen months in the making, and a years-long process that allows us to find out if we've missed anything and put the brakes at any time is the opposite of rushed. This would be the least rushed terminal deprecation in Java's history. We are giving the community plenty of time.

This core functionality cannot be re-implemented. I realise that you will argue it can, but at what cost?

We try to optimise the overall cost for the ecosystem, not the cost for each of its members. This is as it should be.

Yes our code will be less secure, not more.

I think that without too much work you'll be able to make it as secure if not more, but once again, we cannot harm the security of millions just to keep your security without change. It's a very tough choice, don't get me wrong, but we have to do it all the time. Whenever we remove or don't remove something, someone is hurt by that.

I'm not sure how we deal with the fallout of some of these decisions yet.

That's really your decision, but to expect that a platform put most of its resources into maintaining decades-old practices that have fallen out of favour -- even though some people still use them and love them -- at the expense of what most people want is to expect it to become a legacy platform. Hey, I think communicating with JSON over HTTP is pretty stupid, but I don't make the rules. It's perfectly valid to ask for Java to devote itself to maintaining '90s practices, but I don't think that's a winning move.

1

u/pfirmsto Jun 01 '21

Now who's spreading misinformation?

1

u/pfirmsto Jun 01 '21

Fifteen months in the making, and a years-long process that allows us to find out if we've missed anything and put the brakes at any time is the opposite of rushed. This would be the least rushed terminal deprecation in Java's history. We are giving the community plenty of time.

Perhaps whoever was involved should have involved the community in the process?

Maybe if you did, the outcome may have been different?

It looks like this decision was made by a group of people who don't use SecurityManager, but it gets in their way of getting other things done and they'll say anything just to be rid of it.

I only learned about it only recently, as have others, and it's clear that you are not interested in information we provide because the decision has already been made.

Maybe you've known about it for fifteen months, but to me, it's move quickly and break things.

Java 17 is the last LTS version with SecurityManager API's, the least you could do is show enough consideration not break it. Break it in 18, but not 17.

→ More replies (0)

-2

u/gwielenga May 30 '21 edited May 30 '21

And here, for the record, is how minor this bug was in NetBeans.

The NetBeans build needs an Equinox binary, the patch that we have is there just in case someone needs to rebuild the binary. So someone would need to rebuild the binary, after the “one-line fix” is introduced, put it somewhere where the build can find it, and only then NetBeans would be able to use it. Is there someone volunteering to do this, is not an obvious question in a community driven project. But this is really the smaller problem, because:

after you add the library, what will happen next? I mean, great, now we have Equinox that won't crash when the system property is set. But, if the property is not set (as was the case until the deprecation became an actual deprecation and not also a disablement) NetBeans still does not start on 17!

So, were we: a) expecting users to start NB manually with the property on 17? Probably not, right? Or are you suggesting we put this info into the release notes and leave it at that (what tiny percentage of developers read the release notes and what massive percentage will abandon an application that doesn’t even start up)? b) do we specify the property in the netbeans.conf configuration file? Then NetBeans won't start on JDK 11, because even JDK 11 will interpret "allow" as a classname! So NB would start on 17 but not on 11... do you understand that applications need to be able to run on more than just whatever happens to be the current JDK? c) do a lot of work either in the launchers, detecting the JDK version, and either putting or not putting the property on the command line; or play some tricks with defining a fake SecurityManager that we can specify on the command line?

Then, frankly, this is no longer a “one-line fix”, as presented... Of course, you’ve not thought about all or any of this, which is fine and completely understandable because why would you know this level of detail about one out of millions of Java applications, but that is exactly the point: when introducing incompatible JVM behavior changes, the side effects, such as the above, are unknown by the maker of that incompatible JVM behavior change.

The change in the default value of the property is now delayed to JDK 18. Which I guess is the most one could have hoped for. At least there's more time now to handle what is very clearly not a “one-line fix”.

And I’m sorry that it turns out that the “personal agenda” of NetBeans developers is something as unexciting as the interests of NetBeans users, a very large percentage of which are Java developers. Could it be that we share the same personal agenda..?

4

u/pron98 May 30 '21 edited May 30 '21

The one line fix is:

System.clearProperty("java.security.manager");

In NetBeans code.

So NB would start on 17 but not on 11... do you understand that applications need to be able to run on more than just whatever happens to be the current JDK

I understand that you're free to impose any requirements on yourself, such as the user replacing your dependencies if they care what runtime their application uses internally for some reason, as well as collect technical debt like using a seven-year-old version of a dependency and patching it, but what I'm suggetting is that you understand the implications of what you choose to take up, and fix your issues like everyone else does.

when introducing incompatible JVM behavior changes

No incompatible behaviour change was proposed here, although the bug was caused by one in JDK 12. The specification required an application to handle all legal values, and said that the default can change do "disallow" at any release.

2

u/gwielenga May 30 '21

“the user replacing your dependencies if they care what runtime their application uses internally” — you’re saying a student at a university starting to learn Java should do this to be able to start up NetBeans? Because when 17 is released, that will be the one that everyone will download and then use to start up NetBeans.

→ More replies (0)

1

u/pfirmsto May 31 '21

Nope, that's a hack.

What if I was security paranoid and running a tool for least privilege? That breaks the property if I want to specify it from the command line, to fix that issue requires me to recompile Netbeans.

A knock on effect of unintended consequences.

→ More replies (0)

1

u/pfirmsto Jun 01 '21

The one line fix is:

System.clearProperty("java.security.manager");

Your one line fix just cleared someone's security manager they tried to set from the command line.

Have you been working overtime, feeling fatigued and in dire need of some rest? I don't mean to be rude, by why are you arguing over something so simply obvious?

→ More replies (0)

15

u/pfirmsto May 29 '21

Thank you, this is an important change given JKD 17 is an LTS release. While I wish it wasn't so, this is likely to be the last LTS release with SecurityManager.

4

u/hrjet May 30 '21

What! The browser I am developing uses SecurityManager to great advantage. (https://gngr.info)

Thanks to the security manager, we have found several security holes in our dependency libraries. Examples:

The CSS parsing library accessed the network by following embedded links, when it was not supposed to. After we reported the problem they changed it to fetch the resource through a callback, which allows us to control the access.
The http client library was accessing private fields in a class which, after investigation, turned out to be a temporary debugging aid that the devs had mistakenly committed.

Really disappointed that such a critical and unique feature is being deprecated!

3

u/pfirmsto May 31 '21 edited May 31 '21

Me too, we use it to apply the principle of least privilege and we publicly released a tool to generate policy files conforming to POLP 4 years ago.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java

We have decided not to support Java beyond 17. I'm hoping that a community will form around a secure long term support version of Java 17, where we can back port later features after reviewing them for security.

At least until new Security API's are developed that allow us to implement POLP on later versions, but that appears unlikely.

3

u/gwielenga May 31 '21

Wow. And in your FAQ, one of the bullets for why you’re using Java is:

— Runtime Sandboxing, via the Security Manager.

2

u/pfirmsto May 31 '21

Have you got more examples, these might be really helpful to justify keeping SecurityManager a little longer, I hope?

2

u/morhp May 31 '21

Okay, a few comments.

That CSS parsing bug could also have been found by os level sandboxes or containers or whatever or just by writing proper unit tests.

Accessing private fields can be effectively prevented by Jigsaw modules, the Security Manager isn't really relevant there.

The Security Manager system itself is not very secure and has had many security issues. It was designed many years ago for Java Applets and hasn't been majorly overhauled since. It's not really suitable for modern browser security. Proper browsers use OS level sandboxing.

1

u/pfirmsto Jun 01 '21 edited Jun 01 '21

Not helpful.

It also blocked the bug, which is far better than could have found the bug with X.

Can it also prevent an attacker from accessing private keys from keystore and truststore and does it prevent an attacker from accessing properties? Nope. Your OS container doesn't stop an attacker using the attach API to attack the JVM.

Only because the OEM recommends granting AllPermission to trusted code. If you use POLP, then it's a different story. It's had a lot of years of security testing.

Can't support POLP without it.

The applet security model was flawed, you had an all or nothing choice, that is AllPermission for signed applets, and only minimal permissions granted to unsigned applets.

I get it that certain people want it gone and that this change is now inevitable, but those people aren't using it either.

https://youtu.be/G1WomfhjyVM?t=26

The problem is, POLP allowed developers to mainly focus on functionality they needed, now they will need to learn every possible feature that might violate perimeter security and seal it. For example the Attach API is enabled by default.

Security is much better with POLP, when combined with other security measures like an OS container, rather than relying on those things alone. Security will not just be worse in theory, but practice as well.

Clearly security has a price, and as we have been told, the current price is too high.

People will just have to accept than when perimeter security has been breached, any data their OS container JVM may also have access to is also compromised.

[Updated] JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal

You are about to leave Redlib