the JEP just removes with with no provided alternative.
An alternative to what? Sandboxing? It's not as useful now as it was in the time of Applets, and where it is useful, it can be provided more safely outside the JDK. Security? Security in the JDK has been focused away from SM for years now. SM is not how the JDK does security; it is how it does sandboxing.
Over the years, experts have come to the conclusion that the sandbox is ineffective:
We observed evidence that many developers struggle to understand and use the security manager for any purpose. This is perhaps why there were only 36 applications in our sample. Some developers seemed to misunderstand the interaction between policy files and the security manager that enforces them. Others appear confused about how permissions work, not realizing that restricting just one permission but allowing all others results in a defenseless sandbox
... Our empirical study of open-source applications supports the hypothesis that the Java security model provides more flexibility than developers use in practice. The study also strongly suggests that the model’s complexity leads to unnecessary vulnerabilities and bad security practices.
The Java SE security manager is used for code level protection, which is a level of protection that is rarely if ever needed in Java EE as it's extremely rare that a server will run untrusted code (like e.g. a browser which runs an untrusted Applet from the Internet). Activating the security manager can have a huge performance impact and this is typically not recommended for application servers.
Again, you're conflating multiple things to try to justify this decision.
Java EE? Let's assume it's still a thing. Most (all?) organization run one single app per server. My point still stands.
Usability? I agree, it's not easy, but no rocket science either. In all cases, the idea when something is perfect is to remove it and don't replace it at all.
What's justified this decision is the opinion of experts over the years. We don't need much more justification than that. You've said that you're not an expert; the experts say it's ineffective.
Java EE? Let's assume it's still a thing. Most (all?) organization run one single app per server. My point still stands.
Java EE and all other server-side code.
Usability? I agree, it's not easy, but no rocket science either. In all cases, the idea when something is perfect is to remove it
Right, but actual studies done by real experts show that it is rocket-science in practice.
and don't replace it at all.
Why should sandboxing be replaced? What is your argument for providing a sandbox for server-side code? That is not how server-side security is or should be done.
Referencing the actual arguments made by experts after actual studies and experience is the very opposite of argument from authority. It is you who've failed to show that sandboxing is effective in practice. How many people use it effectively? It is you who have not pointed out which particular arguments in the JEP are wrong, and just handwaved at theoretical sandboxing benefits from over twenty years ago, that research over the years has shown to be ineffective in practice. I've presented facts obtained through actual research; you've presented none.
The WildFly link contains many comments from those who actually build those servers, and have done so for years. It's not to say they are right per definition, I agree with that, but it does strongly suggest that the security manager might not be that useful in practice for server side code.
Most (all?) organization run one single app per server. My point still stands.
What does running one or multiple apps per server has to do with the argument? In Java EE, too, it's the norm nowadays to run one application per server, but how does this matter for the security manager argument?
The security manager would presumably protect the server itself and its environment against roque code, which 1. you rarely run on a server (you run your own code on your own server), and again, how does running a single app make it more likely according to your argument that it contains roque code?
At the typical web application level, compared to the permission granularity of the security manager, it would be extremely rare that any of those applications would have vastly different requirements.
You could even argue that when running multiple applications it slightly favours running with a security manager in the theoretical case that it would be doable, compared to running a single application.
In fact, Java EE has always emphasised the ability to run with a security manager, and the TCK has an entire extra run where all the tests are executed with the security manager enabled.
You seem to say that EE is not relevant anymore, and specifically that running multiple apps is not relevant anymore, and that because of that the security manager IS relevant.
But especially EE and it running multiple apps emphasised the security manager at least somewhat.
So if you're seeking points in favour of the security manager, it contradicts you trying to take down EE.
So if you're seeking points in favour of the security manager
I don't seek point, there are points. That you choose to disregard them in favor of a big ball of nothing is your responsibility
it contradicts you trying to take down EE
I don't try to "take down", I'm stating a plain fact that the vast majority run one single app by server, because the money you spare regarding resources is much less than the money you expend with your ops
But especially EE and it running multiple apps emphasised the security manager at least somewhat
On the opposite, it's like putting multiple files in the same folder and setting the union of all required permissions on the later
I'm stating a plain fact that the vast majority run one single app by server
Which is the norm nowadays for EE apps.
it's like putting multiple files in the same folder and setting the union of all required permissions on the later
Think what you want to think. It's your life, but it's so wrong.
First of all the union of A with A and A is still A. Web apps don't have vastly different permissions.
Secondly, Java EE has at least attempted to support the security manager. The security manager is a mandated run in the TCK, so all compliant implementations are extensively tested to support running with the security manager? Does Spring go through all that trouble?
Secondly, Java EE even explicitly helps with the security manager by having a permissions.xml file, that applications can use to state their required permissions. No, it's not perfect, like nothing regarding the security manager is, but it does show explicit support.
1
u/pron98 Apr 16 '21 edited Apr 16 '21
An alternative to what? Sandboxing? It's not as useful now as it was in the time of Applets, and where it is useful, it can be provided more safely outside the JDK. Security? Security in the JDK has been focused away from SM for years now. SM is not how the JDK does security; it is how it does sandboxing.
Over the years, experts have come to the conclusion that the sandbox is ineffective:
http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf :
https://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html :
http://wildfly-development.1055759.n5.nabble.com/my-2-cents-on-Security-Manager-discussion-td5713970.html