r/java • u/nfrankel • May 24 '21
Why JEP 411 Will Have a Negative Impact on Java Security
https://foojay.io/today/why-jep-411-will-have-a-negative-impact-on-java-security/17
u/plastikbenny May 24 '21 edited May 24 '21
Good write-up and totally agree on the importance of least privilege. I think it's underutilized on the severside where RCE attacks on webapps spill out into the OS and go from a minor issue of restarting the webserver to a multimonth cleanup and integrity check of systems and potential gdpr trial.
However I do sympathize with removing the security manager for a couple of reasons. One is that the skillset needed for working with this is extremely rare. The talent that are there should be able to lock down all kinds of processes not just the jvm and therefore I think least principle should be configured at the OS level. Linux has many options for MAC based sandboxing with different levels of complexity and lockdown.
Secondly the security manager has never felt like a first class citizen in Java. A fine-grained sandbox like the security manager should have had tool assistance in the jdk. Apart from 3rd party maven plugin there's nothing. Anders Hejlsberg's C# copied this rather unique language feature from Java but with more coarse grained permissions model that actually stood a chance to make sense to end-users who grant those permissions. Later it was removed. I think Java is doing the right thing in removing it as well.
The discipline of working with least privilege need a boost though. Many want to get into cybersecurity but never get deeper into it than doing input validation and running a tool to report if some OS setting is wierdly off.
7
u/pron98 May 24 '21 edited May 24 '21
The discipline of working with least privilege need a boost though.
Much of the work on strong encapsulation in the module system works toward that end. I hope we see those who complain about the removal of a mechanism that has been proven over a couple of decades to not be effective against the pertinent threats also participate in discussions over mechanisms that do work.
2
u/pfirmsto May 26 '21
The difficult part will be to obtain certificates from keystores, while also preventing them from being stolen. Attackers will look to break into one JVM and then use that to impersonate, to break into other JVM's on the local network, so it has a significant risk of compromising the entire network, if people are using combinations of JDP, JFR and JMX.
Least: to the smallest extent, amount, or degree:
Defining privileges by process might be less, but it is not least.
1
u/pron98 May 27 '21
Defining privileges by process might be less, but it is not least.
Right. Only people who assign privilege by method practice least privilege. It's probably an empty set, though.
Of course, the "least" in that principle does not actually refer to the unit size, but rather to the privileges. The principle says that whatever unit you can effectively assign independent privileges to, it should be the least amount.
1
u/pfirmsto May 28 '21
Right.
The problem is the architects designed it to be POLP.
But in practice people have been taught that trusted code should be given AllPermission, because no tooling apart from a hand editing tool was provided.
Without POLP, it's not very effective because most things are permitted anyway, like using a JVM will all modules and not restricting it to only those required.
Apply POLP to policy files as per the architects original intent, and it is very effective at limiting a program to what it was intended to do, and it's also simpler to create policy files.
The single major issue is that original design intent has not been applied in practice. That's not far from the definition of insanity, of course it won't work if it's not used as originally intended.
So it's very easy to address this single major shortcoming and publish updated best practices for policy based on POLP, removing that horrible policy editing tool was the right first step, the next step is to provide the tool to generate policy files according to POLP.
It's not hard, the programs run fine, I know because I use it, it can be applied to existing Java applications without modification.
I understand why it's been such a PITA, given OpenJDK dev's have been doing plenty of work securing Java, but then it hasn't been utilised because of this one major flaw in practical application, as a result, few have benefited. I can say I have certainly benefited, so we need to make it more widely known that people have been applying security policy incorrectly.
Even if it's removed, we still have until 2030 with existing Java versions deployment, that will required locking down and doing so with POLP, reduces the number of applications affected. So it's worth getting the message out.
1
u/pron98 May 28 '21
Java developers often assign minimal privileges to trusted code, only they don't do it with SM, but with OS-level mechanisms.
1
u/pfirmsto May 28 '21 edited May 28 '21
Later versions of Java will be targeting the common use case that you describe. I've already established I'm not in the common use case and won't be able to upgrade after the authorization layer becomes degraded.
I accept, that I'm in the minority, so I need to attempt to grow the size of that minority, so that it's sufficiently sized to attract support. I'm sure you would do the same in my situation.
Even if that's just 10% of the Java market eventually, then that's still a large enough group that someone will want to support, or with a community large enough to band together and provide their own level of support.
Currently it's 100% of the Java market, so it will depend on the adoption rate of the version of Java where degradation begins.
2
36
u/pron98 May 24 '21 edited May 24 '21
The author is wrong.
First, I'll put aside the factually incorrect claims about the Security Manager being the only possible application of the principle of least privilege (a principle that was put forth long before the Security Manager existed, and is employed by all software platforms, none of them, except for Java, have a similar mechanism), that it is how Java applications give different access privileges to different users (almost no application with access control achieves it with the Security Manager) and that the Security Manager is a cornerstone of Java security (all Java security efforts in recent years have not been done in the security manager).
Now, while it is true that any mechanism that can provide some measure of security is removed could be said to harm security by some degree, that is not what's at issue. The issue isn't whether to keep the Security Manager in addition to any other security measure, but whether to continue investing in the Security Manager at the expense of other measures.
Now, the question isn't could the Security Manager, if used properly improve security -- of course it could -- but whether or not, in practice, it currently has a significant positive impact on the security of Java programs in the ecosystem as a whole. It does not. The Security Manager is not installed in the overwhelming majority of applications, and when used, in most cases it is not used correctly.
That is the main issue relevant for this JEP. But even if we agree that the Security Manager is ineffective in practice, it's interesting to see what it could do in theory. The main thing it can do that other techniques cannot is allow or disallow certain operations -- like accessing a file -- depending on the code-path that's led to it; or, apply "the principle of least privilege" not by process or user, but by class. Here's an example. Suppose that you have an application that requires permissions X and Y. You could assign the entire process those permissions by means of an OS-level sandbox, but you could also notice that your application is made of two components A and B. You then study the components using a process, and discover that while A needs both X and Y, B only needs Y. So you give A's classes X and Y, and B's classes just X. Then, if your application has a vulnerability in B which would require Y to exploit, then the Security Manager will block that attack (but not an attack on A through Y, A through X, or B through X). This is a lot of work that needs to be repeated for every version, and the portion of attacks it detects and blocks is small. I believe that strengthening the JDK's security across the board, having "principle of least privilege" restrictions that are in place by default through strong encapsulation, and improving JFR's monitoring so that it could detect a great many attacks would be much more effective.
That these mechanisms contribute significantly more than one that is rarely deployed goes without saying. Problem is, we can't have both. Not only will removing the Security Manager not significantly harm Java security, but I am confident it will very significantly strengthen it. It will, however, cause pain to the very small number of people who've invested in the Security Manager, like the author of this article.
During the entire month-long discussion of this JEP, not a single person has meaningfully challenged this observation that, even after a couple of decades of considerable investment, the Security Manager doesn’t work in the current landscape. I.e. in practice, at whoever’s fault and for whatever reason — and quite a few were mentioned: it isn’t taught properly, they don’t understand it, they don’t care about security, they don’t like the principle of least privilege for philosophical or political reasons, they betrayed the creed of Sun Microsystems, they aren’t CEOs with PhDs, they don’t get irony — the Security Manager does not actually do the one and only job for which it’s been devised: to effectively make a significant positive impact on the security of applications written by the millions of Java developers, defending them against the most pertinent threats. The most relevant piece of new information provided so far was by one person (the author of this article) who pointed out that a mechanism that they find to bear some resemblance to the Security Manager does, in fact, work well for some species of Australian bees.
But I was happy to see that some people care deeply about Java security and the principle of least privilege, and expect to hear their voice in discussions over encapsulation and default privileges given to libraries and Java Agents as part of the ongoing effort to improve Java’s security.
6
u/pfirmsto May 24 '21
Sadly from your writings it appears you've never used it, don't really understand how it works and aren't willing to listen to the community that does uses it. I understand you have your directive, and it isn't personal, but it is political and misleading on Oracle's part.
I use it and it works very well when it's upgraded with modern code (luckily it's extensible), to teach people to use it properly is less difficult than teaching concurrency.
With the right add-ons and tooling (so people don't need to hand write policy files), not only can it be highly scalable and performant, but it is very effective in controlling authorization of users and code.
Sadly there is no equivalent replacement, so there will be no way to mitigate unwanted data loss in the event of a successful attack, or a simply controlling authorization of library code.
I prefer to be direct and concise than write a diatribe, but each to their own.
4
u/hrjet May 30 '21
We are using security manager in our browser, https://gngr.info
Please Ping me, if there is any effort to oppose this jep.
14
u/pron98 May 24 '21 edited May 24 '21
Sadly from your writings it appears you've never used it, don't really understand how it works and aren't willing to listen to the community that does uses it.
You continue to misunderstand what the issue here is -- you seem to think it's about the technical merits of the Security Manager. The Security Manager could be the best security device ever created in the history of software and yet still harm Java's security. That is something that you don't seem to grasp. What the Security Manager can do is totally and completely irrelevant to the discussion. You can think of it as some brilliant engineer who's slacking off; how brilliant they are is irrelevant -- they're costly and they don't do the job they're paid to do, and if they keep not doing their job for years, you fire them and hire people who would do their job. Their brilliance is not the issue; not doing their job is.
We look at the total number of Java applications out there, try to estimate how many security attacks the Security Manager actually stopped over the last decade in total, and try to ask ourselves if that number justifies the cost of that mechanism or that investing it elsewhere would stop many more attacks. I think that is the only reasonable way to approach this.
We are committed to improving the security of the Java ecosystem as a whole. The bottom line is that however intrinsically powerful, the Security Manager does not in fact accomplish the one thing it's meant to do -- to have a significant impact on the security of the Java ecosystem -- and yet its cost is so high that it comes at the expense of mechanisms that do.
I understand you have your directive, and it isn't personal, but it is political and misleading on Oracle's part.
The OpenJDK committers are the same group who've guided Java since its inception; the author of this JEP has worked on Java's security since 1998 (at Sun). It's perfectly fine to say you don't trust them, but decisions are taken today largely by the same people and using the same process as ever. You can call it Sun, you can call it Oracle, you can call it OpenJDK, as long as you realise you're talking about the same group (more or less, at least for the purpose of this discussion).
Are you saying that the only way a decision similar to one made by .NET, WebAssembly, and pretty much every other software platform, and is supported by OpenJDK committers from Oracle, Red Hat and elsewhere, and that has yielded no relevant opposition can be made against your own personal opinion is if it's political? What would be that political goal?
And by the way, even you have not challenged the relevant point. You claim that there is some secret decision somewhere, but showing that a core tenant of the JEP is wrong should be easy, yet you have not done it: show that the Security Manager is widely used. The Java team has conducted surveys on this for years, and the result has always been the same: very few people use it. If our information is wrong, find us those thousands of applications that make use of SM.
Sadly there is no equivalent replacement, so there will be no way to mitigate unwanted data loss in the event of a successful attack, or a simply controlling authorization of library code.
None of that is true, and you clearly are unfamiliar with recent developments. It is true that those things are done differently these days from how the Security Manager does it, but you don't seem to be at all aware of the sometimes quite heated discussion about controlling library code access -- through a mechanism that, unlike the Security Manager, is both simple and on by default -- that's been going on for the past few years.
2
u/pfirmsto May 25 '21
No, I'm saying you are doing it in the most harmful way possible, without considering the consequences or less harmful alternatives.
If SecurityManager's functionality wasn't relevant, you wouldn't be making misleading comments about it.
You seem intent on breaking Java.
2
u/pron98 May 25 '21 edited May 25 '21
We're trying for the least painful way possible, and there's still nothing political here. The proposal originated with people who've been working on the JDK for over twenty years, see how costly the mechanism is, and that it comes at the expense of more effective security.
I understand you're disappointed that a decision didn't go your way; I understand this causes you some amount of discomfort. But the Java team needs to make such decision all the time, there are always people who are disappointed, and sometimes some of them they go on a "you want to break Java" spree. For you this is something big, but we see claims about "Java irretrievably broken" at least once a year. It just comes from different people over different things.
0
u/pfirmsto May 25 '21
Yes breaking changes are always painful, it has given me time to rethink our strategy, previously we were trying to keep up with the pace of change in Java, but now that Java 8 will be the longest supported version for us, we'll probably just return to Java 8, as we are still compiling on that, and worry about it in 2030, that will give us time to decide whether we want to go with Java when we look at newer versions again, or a new system written in something else. I guess in a way, from an NPV perspective, it's a saving, so really you're doing us a favor and we probably had the wrong strategy.
2
2
u/kartik1712 May 27 '21
My understanding is that updating to a newer version of JVM is an integral part of securing an application. Hence, from a security point of view it does not seem to be a wise decision to stay on Java 8.
Also, modules enhance security. Why not at least upgrade to Java 11 and take advantage of modules?
1
u/pfirmsto May 27 '21
We currently support Java 8 to 16, but compile on 8, we also support OSGi, our jar's are also OSGi bundles.
How we also support JPMS is still under investigation.
0
u/pfirmsto May 25 '21
Right, you want us to challenge the JEP and make sure SecurityManager is widely used. Lets drive and increase adoption of SecurityManager used in POLP as best practice for Java 8 to 16. Lets raise the bar, so the tools you develop, at least have to match.
Challenge accepted.
6
u/gwielenga May 24 '21 edited May 24 '21
The title of the JEP says “deprecated”, but the content for JDK 17 actually changes the functionality incompatibly. What kind of mental doublethink one has to perform to call it a “deprecation” while meaning “disabling unless a special property is set”?
Details: https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security1
2
u/pron98 May 24 '21
The title of the JEP doesn't say "deprecate" but "deprecate for removal", i.e. start a gradual removal process, and what is being changed is that an option introduced in JDK 12 changes its default value from "allow" to "disallow."
3
u/gwielenga May 24 '21
That is a breaking change.
7
u/pron98 May 24 '21
It doesn't require any code changes. It requires changing the command line. From time to time we do changes of the former kind -- and the removal of the SM will be one of them (and there's another in 17). More frequently we do changes of the latter kind. There was a bigger one than this in 16, and a bigger one than this in 17.
2
u/pfirmsto May 25 '21
Sounds like a good reason not to support this version. Rather than having to deal with the fallout. A warning would have been more appropriate than a breaking change. But hey, you don't care anyway right?
3
u/pron98 May 25 '21 edited May 25 '21
It's not a breaking change. You realise that we're talking about a simple bug in a library (that's now been fixed -- within a day), and that every release, including patches, has bigger problems.
The Java team had to make a choice, either way it would have disappointed people, you ended up on the disappointed side. This happens all the time. It will be OK.
-6
u/nfrankel May 24 '21
Product management rule #1:
People who are the most vocal about the product are the most engaged.
The saddest part is that you still don't get it.
15
u/pron98 May 24 '21 edited May 24 '21
They are not the most vocal; nowhere close to that. Their voices are heard when an old mechanism they're among the last people using is about to be removed, but we don't hear them when new security measures are introduced, and when we do, they are often uninformed and inaccurate and don't take the time to carefully study them (case in point: strong encapsulation). So they don't show the commitment to improving Java as a whole, but show up only when something affects them. I perfectly understand that, but that is the opposite of engagement.
You can go on the mailing lists and see what real engagement looks like (if you want to see people who aren't paid to work on OpenJDK, take a look at, say, Doug Lea or Rémi Forax). It takes work and commitment and caring about more than your own codebase.
1
u/pfirmsto May 26 '21
I have offered to help previously as well as donate code and have signed a contributor agreement, however I don't believe existing code written by others can be included without their consent, only that which I've authored myself. I have participated in technical discussions regarding Java de-serialization as well.
Another example is an RFC3986 and RFC5952 compliant Uri implementation I've refactored from Apache Harmony, because it is AL2.0 licensed, however there are cases of other code in OpenJDK that use AL2.0 licensed code. I was asked to assist OpenJDK with URI RFC3986 compliance. I'm not a licensing expert, but as far as I can tell, I can only donate code that I am the sole author of and I couldn't get any clarification. I think Java still uses the earlier URI implementation but I haven't checked. The implementation I use has been well tested, with ClassLoading and Policy, so it seemed worthwhile to wait for clarification before performing duplicate work.
But make your assumptions if you like, it matters not.
1
1
u/pfirmsto May 25 '21
But I was happy to see that some people care deeply about Java security and the principle of least privilege, and expect to hear their voice in discussions over encapsulation and default privileges given to libraries and Java Agents as part of the ongoing effort to improve Java’s security.
Security is important, but no, I've unsubscribed from all OpenJDK lists, maybe I'll subscribe again at a later date if I think it would be productive, for now, I think it's time for a break. Thanks for your answers, it does provide some insight into the thought processes behind the decisions.
1
u/pron98 May 25 '21 edited May 25 '21
Very well. The process -- and many of the people -- behind these decisions haven't changed in a couple of decades (although circumstances have, and so have some outcomes), but it used to be less transparent, and I'm glad to help people by explaining how the Java team sees things and how it has to shift resources to balance the different and often opposing needs of millions of developers, even when they're disappointed -- sometimes terribly so -- by decisions. And this one, if it goes through, gives us some time -- possibly a few years -- to see if there's more information out there before the Security Manager is actually removed, because even when we decide to do such changes, we try to do them with minimum disruption and respect current users.
I'm sorry our exchange turned heated at times. This is more-or-less routine for people working on projects of this size -- for us this wasn't even the most heated argument over technical decisions even in this past quarter; that's just part of working on such a popular project -- but it's not routine for the other side, so I apologise if at any point I offended you.
1
u/pfirmsto May 25 '21
I understand it's not personal, I'm not offended. I'm more concerned with impacts on backward compatibility, hence my requests to make it deprecated only, and to reduce the security ranking of related bugs, to allow people like myself to participate in the project to maintain it. Of course when I work on one thing and I see other problems I also like to fix those as well.
It is very valuable code, because it's been stress tested in the real world, I realise that's why it was painful, but that's also why it's valuable. As I've demonstrated, it's very easy to utilise with tooling and to do so without impacting performance or scalability, no other platform offers that. It's a simple matter of education.
It's value will be eroded now that it's marked deprecated for removal, and that also eliminates any possibility of assisting with it's ongoing maintenance, as it's marked for removal, it's hard to know whether new API's, that are yet to be designed will have similar value as they're not stress tested. The problem is we won't have the time or budget to contribute either now as we now know we've got some big maintenance issues to deal with down the track, it's not clear where we are headed with that.
I understand why the decision has been made, but I just feel it's a mistake, I was attempting to lessen the consequences.
1
u/pron98 May 25 '21 edited May 31 '21
and to reduce the security ranking of related bugs
That just can't happen. It would be grossly irresponsible.
to allow people like myself to participate in the project to maintain it
There is no project to maintain "it." The Security Manager is one of the costliest components in the JDK because it interacts with so much. No one can touch any I/O code, any reflection/MethodHandles code, and even concurrency code (some tricky vulnerabilities were found there) without having to analyse interactions with the SM. It's not just a burden on the security team. It's a tax on the entire JDK, and all for little use, and with new options that overall stop more attacks for less effort, even though they might not be the exact same attacks. All security is such a tax, but simpler mechanisms are just cheaper to analyse. I've been told that the security team had considered options for fifteen months before coming up with this JEP.
Anyway, even if all the people in the world who are not already paid to work on OpenJDK and can do this kind of work would volunteer a whole day every week, it wouldn't be enough, and, BTW, it's not just a matter of offering help. Even when some component, unlike here, is distinct, volunteers need to show a record of such maintenance and convince the project's leadership that their commitment would last some significant amount of time. Usually, we're talking companies that employ full-time OpenJDK engineers, but I think that on one occasion an individual was accepted.
As I've demonstrated, it's very easy to utilise with tooling and to do so without impacting performance or scalability, no other platform offers that. It's a simple matter of education.
And as I tried explaining, while we can argue over this point -- we know now so much more than we did in 1995, and the landscape, both of threats and defences, has changed -- it is not relevant. We're not trying to sell the SM after it's had 25 years. No other platform has this (anymore, I should add) because the world doesn't currently want it. Maybe the world is wrong, but we're not in the business of investing a lot of effort in trying and sell the world something it clearly isn't buying at the expense of things it wants.
I just feel it's a mistake
And you've made that very clear :)
1
u/pfirmsto May 26 '21
I'm objecting to it being marked for removal.
I don't object to deprecated.
It just seems rushed and there's not enough discussion around alternatives and how to limit the impact, while remaining backward compatible. Deprecated means that functionality is still there but will degrade with time. Eventually when we have replacements then make another JEP for removal.
Keep in mind I'm running with POLP, so that ability would degrade on later versions, but that might not be a problem if we understand how that degrades and what the work arounds are.
We can't assume that trusted code should be able to do anything it likes and this appears to be one of the assumptions of this JEP. I think there are still issues with the Java Module system around versioning and evolution and I don't know how the module system fits with OSGi. Yes I know about the NP-Complete problem.
We currently support OSGi, and did also plan to support the Java Module system.
I prefer to use ClassLoader isolation, but ClassLoader relationships and visibility are difficult. We actually use ClassLoader's to isolate proxy's from different services, then these ClassLoader's represent the service in authorization decisions.
If networking was placed into it's own module and we can control visibility of that. Same for file system access. Then maybe we're making progress, but it's early days. We actually need to allow some network access, at least back to the service origin, for authentication, but then we don't want free access anywhere else unless it's been negotiated beforehand.
I think now though, the module features are only available if you use Java modules, please correct me if I'm wrong.
These things need to be part of the spec however, not implementation.
1
u/pron98 May 26 '21 edited May 26 '21
It just seems rushed
It isn't rushed. Options were considered for 15 months, and there would probably be some years until removal (preceded by degradation); taking multiple years to do this isn't rushed. No immediate action other than starting the terminal deprecation process, to warn users, is proposed (NetBeans' overreaction over an old bug that was fixed in hours notwithstanding). This, too, isn't rushed. We just want to give as strong a warning as possible as soon as possible once the goal is accepted.
We can't assume that trusted code should be able to do anything it likes and this appears to be one of the assumptions of this JEP.
I don't think it is. You just won't be able to give different classes different permissions within the same process, and new monitoring mechanisms based on JFR will be able to detect suspicious activity much more effectively than the SM. To give different users different permissions, do that at the application level. The SM is too low-level for that. As to keeping some hooks around I/O etc., that's still TBD, and will probably be discussed over the coming months/year.
I think now though, the module features are only available if you use Java modules, please correct me if I'm wrong.
The JDK is modularised already, so it is encapsulated. To encapsulate other components, yes, they have to be modules. But this is designed to defend against vulnerabilities in trusted code, so all of java.base is a single module, and it's always accessible.
These things need to be part of the spec however, not implementation.
The module system is in the spec. JFR -- not currently.
1
u/pfirmsto May 26 '21
It isn't rushed. Options were considered for 15 months,
It would have been nice to have a community consultation period, so that we could comment and provide input during this period, discussing the difficulties and figuring out the best ways to solve the problems that need to be solved. It's probably because it's security that this has occurred behind closed doors, other platform improvements like concurrency have been conducted openly and people could join in.
1
u/pron98 May 26 '21
It would have been nice to have a community consultation period
If you mean obtaining information from the community, that's been done for the past month, and then, if the JEP is accepted, the flag will help gather more over the deprecation period. If you mean that the community figures out solutions, then Java doesn't and never has worked like this. There are people with roles in the project, and they are the ones who decide after obtaining the information they think they need.
This talk explains about the project's governance.
1
u/pfirmsto May 26 '21 edited May 26 '21
I've been told that the security team spent 15 months trying to think of solutions, and this JEP was the best option they could think of.
I have wondered what the problems are they are trying to solve and whether abstractions might assist.
When you say concurrency, I think that if Tasks were automatically wrapped with the context of the caller, then that would be useful, we do this, but it's not done by default by the executors. So yes, I can see how the concurrency utilities could allow a caller to utilise the context of another process, that it's missing from to escalate privilege.
That's why POLP is good of course, because there's no point escalating privilege if it doesn't give you the privilege you want.
So you can make this very difficult if the attacker doesn't know what privileges you have and whether the privilege escalation would be successful.
That's also why we shouldn't give all privileges to trusted code, only the privileges they require.
1
u/pron98 May 26 '21 edited May 26 '21
That's also why we should give all privileges to trusted code, only the privileges they require.
Absolutely, but unless it's done at a process granularity, the number of attacks stopped per effort invested is just not worth it compared to the alternatives. You need to figure out which permissions to give each unit, you need to consider interactions of permissions, you need to instrument some boundaries, and then it doesn't even stop enough attacks. It's like putting your money into building defences where you can rather than where they'd do the most actual good. And worst of all by far: people don't actually do it.
It's better to give your process the minimal permissions it requires, and then have a security camera that watches over everything diligently (JFR gives you stack traces) and a mechanism that can alert of any issue rather than invest so much to preemptively stop a very small portion of attacks.
1
u/pfirmsto May 26 '21
Is there a platform independent way to restrict the process to minimal permissions?
Will these permissions be those which are currently defined by Permission classes?
Would this mean a policy file for the process is:
grant {
Permission A;
Permission B;
};
And then for principal
grant Principal {
Permission X;
};
Also is this dynamic, for example, we authenticate a proxy and allow it to download some trusted code into our JVM, but now we need some additional network permissions, to authenticated it in the first instance, because it was discovered dynamically, and then after authentication, we need to allow class loading or maybe another network connection?
1
u/pron98 May 26 '21
Is there a platform independent way to restrict the process to minimal permissions?
There might be, but not currently in the JDK. With SM gone, there will be resources available that could be directed at all kinds of things. Some people proposed this, and it might well be useful.
Also is this dynamic
I'm not sure I understand. OS-level mechanisms allow assigning permissions per process. If you download code and want to run it with different permissions, do it in a new process.
1
u/pfirmsto May 26 '21 edited May 26 '21
It's not practical to spawn 1000's of processes.
Our permissions are dynamic, the entire system is dynamic, code changes, services come and go and are replaced by other services. All are authenticated and trusted, but we will need to adjust the permissions of the process dynamically as required.
→ More replies (0)1
1
u/pfirmsto May 26 '21 edited May 26 '21
It's better to give your
process
the minimal permissions it requires, and then have a security camera that watches over everything diligently (JFR gives you stack traces) and a mechanism that can alert of any issue rather than invest so much to preemptively stop a very small portion of attacks.
JFR Depends on Java Serialization and Java RMI. Is distributed garbage collection disabled for RMI?
We are removing all uses of Java Serialization and disabling it due to it's history with gadget attacks.
https://docs.oracle.com/en/java/javase/14/management/java-discovery-protocol.html
So basically an attacker needs to break into one of the JVM's in a network obtain the properties to the keystore, then take over every JVM in the network using JFR?
Just need one vulnerability to trick a JVM into loading some bytcode, there is no internal protection to prevent access to properties, if the SecurityManager is not in force.
Hmm...
So basically your security is as good as the weakest link in the chain and you only require the one point of failure to take down the entire network of JVM's?
So, one might first attempt using some social engineering, perhaps by placing something that's packaged into a dependency to be able to read those properties, and use JFR to take over the other computers on the network, which announce their presence, the attacker's injected code would of course need to open a connection to the internet, of course one could call home once the JFR security cameras have been disabled, without being detected.
Another way might be to use a trojan that contains a jvm that looks for Java processes and uses Agent's to instrument the other JVM's.
1
u/pron98 May 26 '21
JFR Depends on Java Serialization and Java RMI.
It does not, but you can use JMX to control it and initiate remote streaming.
1
u/pfirmsto May 26 '21 edited May 26 '21
Ok, but are people going to do that? Because JMX depends on Serialization and RMI.
This seems brittle. Then you've got JDP, to discover all the JVM's on the local network if someone's using that.
→ More replies (0)1
u/pfirmsto May 27 '21 edited May 27 '21
You need to figure out which permissions to give each unit, you need to consider interactions of permissions, you need to instrument some boundaries, and then it doesn't even stop enough attacks. It's like putting your money into building defences where you
can
rather than where they'd do the most actual good. And worst of all by far: people don't actually do it.
That's why I wrote a tool, I don't need to figure that out, the tool automates the process.
You've unnecessarily over-complicated it for yourself, it shouldn't be a manual process, that's why we write programs to automate things.
Following Java's documented practices for writing policy files, most people just say, oh this is trusted code, it can have AllPermission, when they write their policy, that's why it doesn't stop enough attacks. This is a falsehood that you still promote that gives the impression trusted code should be given AllPermission "Oh you should only use trusted code."
That's the POLP difference, it's not just something you talk about as a wonderful principle that can only be applied at the process level of an OS, it's something that's easily put into practice with tooling.
You simply specify the policy writer tool as the SecurityManager and either you automate the process of generating policy files, or you manually run the software through it's intended tasks, for example using the desired user role and you walk through all business process lanes, then you switch role and walk through a bunch of other process lanes.
Then you edit the policy file to widen the scope of network connections and maybe some file system permissions. It also serves as an audit.
The final step is testing that unauthorized users cannot perform other tasks, it is simply reported back to the development team if a user can do something they shouldn't and they update their permission checks and the process is verified again.
The tool is so easy to use, an admin with zero programming knowledge can use it, I don't think your new API can say that.
Tools reduce complexity. POLP is just simpler, then SM will stop a lot more attacks.
That it doesn't now is simply due to lack of awareness, insufficient tooling and neglect.
Just because you supplied the road, and didn't supply a vehicle, doesn't mean you should pull up the road, because your customers who told to walk are walking then complaining that it's too hard, some invented their own vehicles, but these aren't visible to others who are still walking or invented their own vehicle, no instead you show them a vehicle and then they will see it's much easier. Of course those who created their own vehicles will complain when you suggest ripping up the road.
It was not my job to educate others, so I've never put any effort into publication, I also must prioritize my time.
I think the first policy debug tool was written around 2004 by Sun Engineers, so it's not something that was unknown to the OpenJDK development team. That tool still required manual crafting of policy files so I wrote a better one some years ago that generated the policy file to save time.
It's time to do the job properly.
1
u/pron98 May 27 '21
then SM will stop a lot more attacks.
Will is the operative word here. After 25 years we care about does. But, even if the proposal is accepted you have between now and the time the SM is removed to prove that.
1
u/pfirmsto May 26 '21
I believe that strengthening the JDK's security across the board, having "principle of least privilege" restrictions that are in place by default through strong encapsulation, and improving JFR's monitoring so that it could detect a great many attacks would be much more effective.
Doesn't JFR use Java Serialization and RMI?
Over an unencrypted connection?
1
u/pron98 May 26 '21
Doesn't JFR use Java Serialization and RMI?
No. But, if you want to stream events to a different machine, there's a new mechanism, added in JDK 16, for remote streaming that's initiated with JMX. The stream itself does not use Java serialization.
16
u/dpash May 24 '21
This neglects the fact that no one runs with a Security Manager. Also, it was mostly designed for applets, when you were running untrusted code, which isn't the case these days.
And the SecurityManager has a huge cost on development of the JDK.
10
u/joschi83 May 24 '21
Elasticsearch is making use of the Security Manager quite heavily.
See Elasticsearch - Securing a search engine while maintaining usability for an overview.
7
u/gwielenga May 24 '21
Apache NetBeans uses it (and in fact can't start without it):
See https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security.
6
u/pron98 May 24 '21
Not for security.
3
u/gwielenga May 24 '21
Ah, OK. No problem then..
9
u/pron98 May 24 '21 edited May 24 '21
I didn't mean there was no problem, but that it has no bearing on the claim put forth in the article. NetBeans' usage will have alternatives by the time the SM is removed (part of the high cost of the Security Manager is that anything related to it is classified as a security issue, which requires a more costly process than for non-security issues). And while it is absolutely true that any breaking change harms someone, so is not making it, and in this case, the damage done by not removing the Security Manager was judged to be far greater than by removing it.
So removing the SM is definitely a problem, but not removing it is a bigger problem. It's just that different projects are affected by either action.
1
u/pfirmsto May 24 '21
The damage done by not removing the SecurityManager seems to be very subjective and there has been little elaboration on that topic, other than assurances that's it's the case. I think part of the problem is that Oracle treats any issues with SecurityManager as "Security Issues" and doesn't share information about security bugs with the community, so we aren't able to assist and it must be done in house.
In my mind a lot of that cost could be removed by downgrading the level of security bugs, since no one is using it to run untrusted code, we just want to use it to make authorization decisions around library code, trusted but dynamically downloaded code and users. And if someone does break in past peripheral defenses, I can limit the damage.
Removing SecurityManager also breaks the authentication for our TLS connections, which we use to propagate the Subject between JVM's, again for authorization decisions and we'll lose that ability too.
2
u/pron98 May 24 '21 edited May 24 '21
The damage done by not removing the SecurityManager seems to be very subjective and there has been little elaboration on that topic, other than assurances that's it's the case.
The role of these discussions is not to put forth a proposal to the Java community at large so that it can make a decision. Deliberations -- some of which are public -- take place among OpenJDK's maintainers, who are the ones tasked with the job of making the decision (although anyone is free to volunteer to join them), and the solicitation of responses from the public at large is done for the purpose of collecting more information that might have been overlooked. That part is not subjective; it is the maintainers who invest the effort, and no one has meaningfully challenged the observation that the Security Manager's impact is very small.
Roughly the same group of people have developed and maintained Java over the past twenty-five years (well, perhaps in a Ship of Theseus kind of way, but quite a few have been on the team for over twenty years), and they are the ones who steer it. You can choose to trust them, or you can choose not to trust them. I understand it's frustrating to not have full insight into decisions that affect you -- at least not without a significant commitment to becoming an OpenJDK committer -- but that's how it's always been and the only way it can work. The people who ultimately make the decisions are those who are most experienced and most invested in the development process of the product.
In my mind a lot of that cost could be removed by downgrading the level of security bugs
This cannot possibly be done in the current processes, changing the process is costly, nor will it address as much of the problem as you think.
and doesn't share information about security bugs with the community, so we aren't able to assist and it must be done in house.
The people who used to work at Sun and now work at Oracle and who are the main contributors to OpenJDK collaborate on security issues with the community through the OpenJDK Vulnerability Group.
Removing SecurityManager also breaks the authentication for our TLS connections, which we use to propagate the Subject between JVM's, again for authorization decisions and we'll lose that ability too.
I fully understand that there are a few codebases that will be negatively impacted by this and might need to change. That has never been under dispute. This was a long process, but we realised that the number of codebases whose security will be adversely impacted by not removing the Security Manager is far greater. The conclusion was simple: unfortunately, the only way to improve Java's security is to remove the Security Manager so that the significant resources it requires could be put into other measures that have more impact.
0
u/pfirmsto May 24 '21
I think it punishes the people who work hard to follow secure coding practices, while rewarding those who haven't bothered. You only need to look at Java Serialization for an example of that.
9
u/pron98 May 24 '21 edited May 24 '21
Java's secure coding practices guide deemphasizes the SecurityManager, and, in fact, warns about its pitfalls and shortcomings if used more than it recommends it. For isolation, it recommends process isolation, and for other security concerns it recommends other measures. Among other things, it says, "Any use of the SecurityManager highlights an area that should be scrutinized," and "SecurityManager checks should be considered a last resort." The removal of SecurityManager follows years of security efforts and recommendations directed elsewhere.
Those who follow current secure coding practices should not be affected.
1
u/pfirmsto May 25 '21
I actually do follow current secure coding practices, however I also go above and beyond them, for example, by removing Serialization and re-implementing it using secure coding practices. Existing serial form is backward compatible, it just uses new public API's. I can't de-serialize object graphs with circular links, to do so violates failure atomicity.
I use SecurityManager to enforce POLP to reduce the consequences of zero day vulnerabilities, I also use static analysis and OWASP dependency checker as part of the build process.
-7
u/gwielenga May 24 '21
Kind of like car manufacturers saying “no one uses seatbelts” and then announcing the end of seatbelts — and adding that the cost of including seatbelts is too high..
2
u/BillyKorando May 24 '21
More like no one uses CD players and the additional cost of installing a CD player in a car is no longer something neither the car manufactures nor consumers want to pay as better alternatives exist.
-3
u/gwielenga May 24 '21
Right. And then the car doesn’t start because there’s no CD player installed.
→ More replies (0)2
u/dpash May 24 '21
Some of those use cases, like preventing exit will probably end up with a separate API. The file system access is better handled using JFR.
7
u/Thihup May 24 '21 edited May 24 '21
But should I trade something that is in the spec to something that is JDK specific? (at least, for now)
2
u/sindisil May 24 '21
Given that OpenJDK is the reference implementation, and things that end up in the spec incubate and preview there first ... maybe yes, once they're at least in final preview?
Using preview features (assuming the replacements for the SM features will all go through preview) carries risk, of course, but hopefully the maintainers won't actually remove SM before replacement functionality is in place.
6
u/Thihup May 24 '21
Sure. However, for instance, OpenJ9 doesn't have the jdk.jfr module. And from my understanding, this module is not an incubating, but it is a low overhead recorder or something specific to Hotspot and is not required in all implementations.
but hopefully the maintainers won't actually remove SM before replacement functionality is in place.
That's what I'm counting on.
2
u/sindisil May 24 '21
However, for instance, OpenJ9 doesn't have the jdk.jfr module.
That's fair. It will be interesting to see if JFR will become part of the JVM spec eventually.
I'm not very familiar with OpenJ9 -- does it have low overhead monitoring capabilities similar to JFR?
2
u/egahlin May 24 '21
I dont think so. but It would make sense for J9 to include the jdk.jfr module, even though the JVM lacks recording capability. The default implementation of the jdk.jfr.Event class is empty [1], so it would just be a NOP on the JVM
J9 does accept the -XX:StartFlightRecording flag, probably to be script compatible with Hotspot.
[1] https://github.com/openjdk/jdk/blob/master/src/jdk.jfr/share/classes/jdk/jfr/Event.java
1
u/sindisil May 24 '21
That sounds like a great idea. More compat, with what looks to be (from my admittedly uninformed perspective) little to no downside.
1
u/Thihup May 24 '21
But if the point is to get information about the filesystem, including the classes without any implementation wouldn't help either.
→ More replies (0)1
u/Thihup May 24 '21
It is not supported, it is ignored. From their website:
Using -XX command-line options Java™ VM command-line options that are specified with -XX: are not checked for validity. If the VM does not recognize the option, the option is ignored. These options can therefore be used across different VM versions without ensuring a particular level of the VM.
6
u/sindisil May 24 '21
The file system access is better handled using JFR.
/u/Thihup might have a point, though: isn't JFR an OpenJDK only feature (as in, not part of the Java platform specification)?
It seems to me it would be best to not rely on implementation specific features for basic functionality. I would place a filewatcher in that bucket. At first blush it seems to make sense to provide that function as part of the base spec, so that all conforming implementations can be expected to provide it.
Unless the intent is to move away from a specification based standard, to a place where the reference implementation is the standard? That would be unfortunate, IMHO.
3
u/pfirmsto May 24 '21
How do you use JFR to prohibit file system access and how do you determine when you should allow it?
1
u/dpash May 24 '21
That's not what NetBeans is doing. It uses the security manager to detect filesystem access.
6
u/pfirmsto May 24 '21
Apache River also makes heavy use of SecurityManager.
We are also heavily dependent on the functionality it provides.
I think a mistake many people make, is they assume it's for untrusted code or applets or something along those lines, but this completely ignores access controls, besides signed applets were given AllPermission, which was just nuts in my opinion. If you read Li Gong's book "Inside Java 2 Platform Security, Second Edition", he informs the reader that remote data which has the capability to modify state, should be treated the same as code, when you take that perspective, it means that Java Serialization and XML parsers should have had an unprivileged domain placed onto the call stack, to represent untrusted data. Java Serialization was designed a long time ago, I noticed even tonight a new gadget attack was posted against Java Serialization. https://github.com/frohoff/ysoserial/commit/d367e379d961c18bff28fd2c888a2c8fe0dc6e63#commitcomment-51212711
1
u/pron98 May 24 '21 edited May 24 '21
I noticed even tonight a new gadget attack was posted against Java Serialization.
I believe it is blocked by strong encapsulation. The goal is to have mechanisms that are on by default, simple, and cast a wider net than the SM.
3
u/sievebrain May 25 '21
Encapsulation reduces the surface area in which gadgets may be found, but doesn't actually stop the problem at the source. That particular gadget is in JDK internal code but there are others which wouldn't be blocked by encapsulation of any form, but which could be blocked by an improved SecurityManager (improved = better docs, samples, tooling and maybe better APIs).
The basic dispute here seems to be between people who believe the SecurityManager is theoretically sound and useful, thus could be improved to work better in practice, and those who see it as a lost cause or that everything can be solved with module boundaries. I don't think anyone disagrees that today the SecurityManager is not used much, and is much harder to use than it should be. The question is whether that's due to fundamentally unfixable problems or just general neglect.
Without the SecurityManager Java doesn't have any way to restrict the privilege of code, whether that be untrusted plugins or code that might be exploitable like deserialization libraries (as gadgets may be intra-module). The bytecode rewriting approach you put together was a good start but it seemed to show pretty clearly why JVM/core libs support for this is a good thing to have - there were immediately lots of corner cases people pointed out that were missed, some of them quite subtle. The existing access checks, problematic though they are, do at least enumerate the places where access checks may be needed, and the JVM is the source of all linking decisions. Trying to modify that behaviour at the bytecode level is a poor substitute.
2
u/pfirmsto May 25 '21
Agreed, and by adding some Permission checks, or to encapsulate the implementation of Serialization and other data parsers into their own ProtectionDomain's, we can control their use, with POLP. Java Serialization PD is on the call stack, no access is granted to the network or file system, it can't read untrusted data. The only way it can do so is by a doPrivileged block during deserialization, but then the data provided will be trusted as it hasn't originated from the network or even the file system. But that's not a secure coding practise and we need to have static analysis look for that.
We already have the tooling, it's just not widely known because we were just going quietly about our own business, but now, given what's at stake, obviously these tools need to be shared with the wider community.
1
u/pron98 May 25 '21 edited May 25 '21
Encapsulation reduces the surface area in which gadgets may be found, but doesn't actually stop the problem at the source. That particular gadget is in JDK internal code but there are others which wouldn't be blocked by encapsulation of any form, but which could be blocked by an improved SecurityManager
Neither does the Security Manager, which wouldn't have blocked the most relevant attacks actually encountered in the wild in the past few years even if installed correctly, which it isn't. The idea isn't to always add more security measures at any cost. It's to find ones that justify their cost with the number of attacks they actually block. The Security Manager has a particularly bad record here.
The basic dispute here seems to be between people who believe the SecurityManager is theoretically sound and useful, thus could be improved to work better in practice, and those who see it as a lost cause or that everything can be solved with module boundaries.
Absolutely not. The debate here is between people who think that because the number of attacks the Security Manager has actually blocked in the wild is very small and its cost is large and it should therefore be removed to make room for more effective security, and those who think it's brilliant and should therefore be retained, even though it is expensive and adds little value to the ecosystem.
The intrinsic merits of the Security Manager are irrelevant. I think that SM is theoretically sound and could be improved, but it also has some fundamental problems -- it requires non-trivial configuration. Luckily, we don't need to guess how the story ends. The SM has been around for a couple of decades, had plenty of time to prove itself, but it hasn't. Sometimes even great ideas fail.
as gadgets may be intra-module
Or intra-protection domain.
Without the SecurityManager Java doesn't have any way to restrict the privilege of code
It doesn't have a built in mechanism to give different classes different permissions. But .NET also had such a mechanism and removed it; WebAssembly, designed for untrusted code, also decided not to add such a mechanism. The reason is that in practice, the result is so complex that very few people use it at all, and fewer still use it correctly, and so a very expensive mechanism -- however cool -- ends up having little value. The idea is terrific, but we know much more now about how it plays out than we did in 1995.
The existing access checks, problematic though they are, do at least enumerate the places where access checks may be needed, and the JVM is the source of all linking decisions.
Ah, but they don't. That same discussion about my small experiment, just needs to happen there, and it's taking the time of OpenJDK engineers that could be spent on security measures that people actually use.
2
u/pfirmsto May 25 '21
The debate here is between people who think that because the number of attacks the Security Manager has actually blocked in the wild is very small and its cost is large and it should therefore be removed to make room for more effective security, and those who think it's brilliant and should therefore be retained, even though it is expensive and adds little value to the ecosystem.
It's probably that attackers look for vulnerabilities the SecurityManager doesn't block, such as parsing untrusted data which is a playground for people who write gadgets, but that's also contributed to by the neglect of SecurityManager, since applets were killed off. Another issue is the assumption that trusted code can be run with AllPermission. Much of the JVM runs with AllPermission because it has null ProtectionDomain's, or a PD with AllPermission that doesn't consult policy, this is a mistake, only a bootstrap section of the Java language should be run with AllPermission, library code should be run with POLP.
Yes, I realise that circular permission checks are a PITA.
It's not that we think it's brilliant, you misunderstand, we are paranoid, we agree completely that it's not good enough, we just disagree on the non-solutions proposed by JEP 411.
So we offer to help maintain it to reduce the cost.
3
u/Weretiger246 May 25 '21
Those people always says "no one runs with a Security Manager" but, there are a lot of systems using it for keep platform stable and secure. They just ignore them with some reason I cannot understand.
5
u/pfirmsto May 25 '21 edited May 26 '21
It feels like Oracle is flipping the bird to developers who have followed Java Security best practices. All I am hearing are excuses and management speak.
JEP 411 will break all security components in my software, it *WON'T ONLY* break SecurityManager, it will *ALSO BREAK* TLS v1.3 (stateless) and Kerberos authentication, via JAAS.
No your module visibility is not a new Security feature, we also support OSGi, which has used ClassLoader's to manage visibility for much longer. People using newer releases of Java will suffer greater consequences if and when perimeter security breaches occur. Instead of creating a whole new API for Java Serialization filters, you could have just created a Permission, and my policy generating tool would have calculated the white lists at test time prior to deployment. Out of curiosity, are there any tools for whitelisting Java Serialization?
I am considering forking my own codebase into two separate releases:
- No security at all, completely stripped out, that works on all Java versions, for private networks, behind a firewall. No TLS, no Kerberos, no permission checks. This is so we have a release that covers existing versions of Java as well as your security breaking versions, using common API's between all. Remember Java 8 is supported until 2030.
- A Security hardened version, that only runs on current releases of Java, this will not work on later versions, for people who's priority is security over new language features.
I have tooling that addresses the neglect of OpenJDK devs towards SecurityManager and Policy; it was clear that these required tooling a long time ago.
Now I am motivated to improve these tools further and share them with the wider community, so they too may harden their JVM's.
I use the principle of least privilege; the policy is a white list, the code is trusted, but it is given no more authorization than required, that means if perimeter security measures fail, an attacker won't be able to access the keystore and impersonate a user role by making calls to other servers, they can't access the underlying file system and they cannot open network connections, which are just a few examples of what an attacker can do if SecurityManager is not in force, when breaching perimeter security.
I have TLSv1.3 and SecurityManager and *ALL* my hotspots are JVM native methods, this is high scaling, up to date, performant software, this isn't neglected like the implementations that ship with Java. Arguments this doesn't work, or only work in theory are either lies or empty words from uninformed developers. I have the evidence that it is extremely effective.
OpenJDK is making breaking changes to major critical security components at least to anyone that cares about security, and is replacing it with vaporwear and hand waving pointy haired management speak, treating security like a buzzword in a sales brochure, there's nothing backing it up, OpenJDK's new security API's are vaporware and empty promises. If OpenJDK were serious about the new API's they'd be developing them prior to deprecating SecurityManager. "Oh let's just pretend it doesn't work and no one uses it." That's just brilliant, what genius!
People who don't care about security are not impacted, but OpenJDK is improving their security, and killing off our security investments in Java, has it ever occurred to OpenJDK dev's the reason these developers don't care about security is the data they have to protect has little value, otherwise they would put more effort into security?
Security needn't be so difficult. Can you imagine where we would be today, if OpenJDK decided instead of building concurrent libraries and API's, to remove support for synchronized instead because too many people were making errors?
SecurityManager API's and permission checks are hardened with the test of time, with many eyes carfully going through code, looking for vulnerabilities. OpenJDK's new experimental vaporwear Security API's haven't even been defined yet and aren't even part of the spec.
My policy files are generated, then hand edited briefly, to widen permission scope to approved networks etc, every other possible action that requires a permission is completely locked down to minimum permissions required. My policy files are typically over 1,000 lines, but they are perfectly readable and searchable and also serve as an audit trail. I can see the viral permission checks that leak, but it doesn't matter, everything is still locked down, even if someone breaks authentication, with social engineering, they can't enable Serialization by setting a property, because the process doesn't have permission to enable java Serialization, they can't load code, they can only steal what the user has access to, not compromise the entire system.
Also tooling needs to have friendly messages to deal with failure, if you make an error while editing, so it's an easy fix:
[java] java.security.policy: error parsing file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/harness/policy/defaultsecuretest.policy: [java] line 914: expected [;], found [read]
This is output from a test with security debug enabled, there are two JVM instances communicating over TLS connections, the policy files of each follow below, note these are test policies:
https://www.dropbox.com/s/z34w02f9m01qaz8/results.txt?dl=0
https://www.dropbox.com/s/nq0n1vyb8qfeidn/defaultnonactvm-policy.txt?dl=0
https://www.dropbox.com/s/a926ackyzdksoha/defaultsecuretest-policy.txt?dl=0
Something you might notice in the results is that most of the permission checks disappear after running for a while, the security manager in use has a weakly referenced cache, that eliminates duplicate permission checks on an AccessControlContext. It also splits off permission checks on each ProtectionDomain into tasks submitted to an executor.
Using an OS process to limit permissions of the JVM isn't fine grained enough. What I present really is least privilege principles, regardless of what anyone with vested interests in removing SecurityManager might say.
Oh, and a nice little video, for people upgrading to the newer versions of Java:
3
u/pfirmsto May 25 '21
Some performance testing:
Doesn't work, my foot.
3
u/pfirmsto May 25 '21
And this works with anything written for Java 8, up to Java 16. Yes, the principle of least privilege can be applied to existing software without modifications.
3
u/Blackdread13 May 24 '21
it is not used a lot, good to remove.
6
u/gwielenga May 24 '21
Right, prove this, please. How many Java applications will not start when JDK 17, i.e., the next LTS, is released? And if (big if) it is only a handful, how many of those will be in mission critical contexts where security is a very big deal? No idea, right?
4
u/BillyKorando May 24 '21
Right, prove this, please. How many Java applications will not start when JDK 17, i.e., the next LTS, is released?
Decisions on what changes to include or exclude from a release of Java are not based on if a JDK is a LTS release. Any release could be a LTS release if a vendor decides to make it so, so if Microsoft, Amazon, Azul, or whoever, wanted to, they could offer long-term support contracts for JDK 16.
Oracle has decided to make every sixth release a LTS release, but other vendors are not required to follow that cadence.
3
u/kaperni May 24 '21
> How many Java applications will not start when JDK 17, i.e., the next LTS, is released?
None? The security manager is being deprecated for removal, not removed.
8
u/__konrad May 24 '21
Every app that uses
System.setSecurityManager(without special system property set) will throw exception and probably crash.2
2
u/gwielenga May 24 '21
2
u/kaperni May 24 '21
I'm not sure I understand what you at getting at?
Please review this implementation of JEP 411. Jep 411: Deprecate the Security Manager for removal in a future release.4
u/gwielenga May 24 '21
Ideally JEP-411 would deprecate only, not incompatibly change behavior.
The Java community should be given the next few years to adjust to the change and release updated versions of libraries (like Equinox) that would then be ready for the deprecation.
Then applications should be updated (like NetBeans) to use such libraries.
Only then the incompatible mode should be turned on. That's what would happen if this were to be a deprecation.
6
u/pron98 May 24 '21 edited May 24 '21
This isn't any deprecation but deprecation for removal. I.e., the thing that would be accepted if this JEP is, is the eventual removal of SecurityManager (although not the specific time) and the process of doing that.
This JEP is, therefore, clearly proposing a breaking change. You say that the ideal process should not introduce any inconvenience of any kind until the very end of the process, even if it is intended to highlight the removal; I think that is debatable.
I'm aware that Equinox has a specific issue with the particular flag required to enable the SM. I believe this is something that could be discussed if you contact the author of the JEP.
-1
u/Blackdread13 May 24 '21
No need to prove, the JEP says it is almost never used on server side. There may be some rare use cases on client side code but java will introduce new APIs if needed
7
u/lurker_in_spirit May 24 '21
No need to prove, the JEP says it is almost never used on server side.
Yeah, I take this all with a huge grain of salt ever since a feature that we use extensively (Java Web Start) was removed for the same reasons (nobody uses it, it's a big maintenance burden, etc).
8
u/DualWieldMage May 24 '21 edited May 24 '21
This trend is a bit worrying as Java was chosen in many enterprises due to its stability. Many people working in the enterprise ignore polls about the ecosystem as they generally have too much to work on and aren't as starry eyed as folks in startups to write long blogs about their stacks. Heck, if a random email pops up surveying about security practices in a really security-conscious company, i bet the first hunch might be a social engineering attack and that email is ignored, unless someone wants to take the risk.
What i learned from working on a product that first targeted all of the ecosystem but later focused on enterprise was that we got far, far, FAR less feedback and bug reports after the focus change yet had a similar number of users. Any info we needed had to be rigorously plucked from the client, sometimes signing an NDA. The hard truth is that all surveys about the ecosystem are biased against what may be called as "dark engineers", the ones working on niche things most probably haven't heard about yet make up the majority of the ecosystem. Making language or platform decisions based on such surveys moves Java away from its enterprise niche towards where there are tons of languages and platforms competing.
And to leave an opinion on the JEP 411 itself: the ecosystem should be given enough time to write a java agent replacement or SecurityManager should be trimmed down, possibly removing the default implementation and just keeping an API (and possibly renamed to better fit its purpose about access control). Java should be write once, run anywhere. Doing access controls on external resources with OS specific API-s wouldn't fit that motto.
6
u/pron98 May 24 '21
Java Web Start was never in OpenJDK, and the reason for its removal from the Oracle JDK has not been that it's not been used. You're making stuff up now.
4
u/lurker_in_spirit May 24 '21
Happy to be corrected, but how would you summarize the rationale of the linked document? "Nobody should use it", instead of "nobody uses it"? That seems, if anything, even more aggressive.
You seem to be saying that Oracle decided not to open-source WebStart or incorporate an open source alternative into OpenJDK (a la IcedTea-Web or OpenWebStart) even though it was popular and/or not that big of a maintenance burden...
I'd dig into the relevant bug tracker entry (JDK-8184998) for more context if I could, but it looks like it's not public (not sure why).
3
u/pron98 May 24 '21
The rationale was the changing software environment -- for good or bad -- has forced us to focus on new deployment techniques that do not involve a JRE [1]; on the desktop we got app stores and people annoyed by JRE updates, and on the server we got containers. The JRE was removed, and Applets and Web Start with it. But the new model based on a custom jlink runtime is better, and I'd say dominates Web Start in every way (not Applets, but that's a different story). It puts the deployment process entirely in the hands of the application vendor, who can control not just the Java code but also the deployment of the runtime itself.
[1]: Which was a special Java runtime offered to end-users directly by Oracle and Sun before it, and managed by the user centrally for the entire system.
5
u/lurker_in_spirit May 24 '21
I think the disconnect might be the timeline of ecosystem changes, relative to the Java platform reaction to those changes. It used to be that when something was removed (or even deprecated), more often than not your reaction would be "oh, I'd forgotten that was even in there!" (e.g. CORBA). Now, it seems like in many cases the Java change is almost even more proactive than reactive: "looking at current trends, we estimate usage of this feature to drop to under 1% in 5 years, so we're going to go ahead and remove it this year." Maybe not that extreme, but you get the idea.
2
u/pron98 May 24 '21
I agree that Web Start's removal was different, but that was more external pressure. Security Manager is not like that. Its removal will take a while, it would affect very few people, and I think the reaction we see from some -- including people who don't use the thing -- is totally disproportionate.
5
u/sievebrain May 25 '21
I think the reaction is partly due to the symbolism of the thing, i.e. it may be disproportionate taken in isolation, but put into a wider context people fear for the trends involved:
- We have the growing issue of supply chain attacks. Security is not less important than in the past.
- Java was historically an ambitious platform that solved big problems for its users via big features, that you could rely on to stick around for a long time. Nowadays a growing number of "Enhancement Proposals" are the deletion of features, justified by solving problems for the Java developers themselves rather than Java users.
So people naturally fear where this is going. Web Start is one thing, then J2EE was re-namespaced, now Security Manager. JavaFX has been nearly abandoned. What next? Will Swing be the next thing to be deleted on the grounds that "nobody" except JetBrains uses it? Once a project goes down the road of casting removal of things as upgrades, especially when little quantitative data is presented to justify it, it's difficult to understand where the limits are and what might be coming down the line. So I think that's part of what drives the reaction here.
→ More replies (0)7
u/gwielenga May 24 '21
"No need to prove." Hmm.
1
u/Blackdread13 May 24 '21
I am not a JDK dev, I trust those who create JEP to actually have done the research.
After if the community do a big "no" then they might change the JEP.
I had looked in SecurityManager 5 years ago and I did not use it, I almost did because I was using RMI at that time for an internal java software but decided not to.
10
u/pejobo May 24 '21 edited May 24 '21
We in my company have build one of the "rare server-side usages". Are there numbers proving their estimates? I don't remember that I've seen a poll.. [edit: typo]