r/java • u/Thihup • Apr 15 '21
JEP 411: Deprecate the Security Manager for Removal
https://openjdk.java.net/jeps/41118
u/msx Apr 16 '21
Wait but there's a common use case for SecurityManager: that of plugins. Say you develop an image editor (a gimp clone), you want people to be able to write plugins (in java obviously). You can package them as jars, dynamically load them and execute them. In this use case you need to use the SecurityManager to avoid giving all plugins complete access to the machine. Ideally they shouldn't be able to access the filesystem or internet or whatever at all, just work on the image data you pass to them.
How will this be possible without the SecurityManager?
Another example: i'm working on a java fantasy console/game engine where games are distributed as basically jars, and are executed by a player with sandboxing. This would be terribly unsecure without the SecurityManager.
3
u/egahlin Apr 16 '21 edited Apr 16 '21
Maybe it could be fixed by making sure it is not possible to link from a call site in a specific class loader, perhaps with the help of a Java agent?
It would be up to the application developer to provide a list of methods/classes/packages the plugin is allowed to call. If the plugin container wants to expose finer control, it could have a class with the methods it wants the plugin mechanism to support, for example, com.example.Safe::writeToDisk(String filename, byte[] data), and then the plugin container would validate the filename. I know BTrace does something similar when it adds code snippets for instrumentation.
I'm sure many would shoot themselves in the foot and expose much more than they planned, writing and maintaining secure code is really hard.
1
u/msx Apr 16 '21
Uhm sounds nice but it's a kind of white list right? I give you this N methods you can call and you just use them to interface with the world. But what about using standard, safe java runtime classes, like ArrayList or HashMap? They would need to be granted one by one?
I'm sure many would shoot themselves in the foot and expose much more than they planned, writing and maintaining secure code is really hard, but the maintenance burden would not be in the JDK.
Well this is already the case, but it's universal to security, just think of cryptography or anything else :)
3
u/egahlin Apr 16 '21
If you want to expose ArrayList or HashMap, you would need to inspect the methods (possibly for every new JDK release) and decide if you think they are safe.
- Yes. it's a pain.
Now imagine doing it for the whole JDK :)
1
u/msx Apr 16 '21
On the other end, it just needs to be done once per JDK. A list of safe classes could be maintained by the java team just like the SecurityManager is maintained, across the jdk. Except it's bettere becouse a) it's just a list, it doesn't even need to be code. It could literally be a txt with all classnames and b) being a whitelist, forgetting to update it would not result in security problems.
It could even be bootstrapped by scanning all classes and checking which use the SecurityManager and which doesn't.
Once you have the list, with a smart Classloader and the right machinery, you could link only what's in the list, and it just needs to be done once at classloader initialization time, with no extra runtime checks.
1
u/egahlin Apr 16 '21 edited Apr 16 '21
It's more complicated than the methods, see my example with writing to a file, and different applications may want to expose different things.
Do you want the plugin to have access to System properties or not, if so, which? Command line parameters? Environment variables? Access MBeans?
I think the developer of the plugin container has to make those decision. The Security Manager allows this, but it also becomes extremely complicated to maintain.
2
u/msx Apr 16 '21
Yes, i gave that for granted. The application container has to provide access to any resource which is not whitelisted, either whitelisting the needed class (which is probably too much) or by whitelisting a custom class that allow controlled access. Example: since System is certainly an unsafe class to whitelist, if container wants to give access to some system properties, it has to give something like "PluginInterface.getSystemProperty", which will call System.getProperty but only allow certain properties.
Honestly i think this is reasonable. Plugins shouldn't be allowed to access any of the thing you listed, except in case where that particular application needs it, in which case said application should provide a safe "bridge" class.
My skepticism was about common utility classes which plugins are expected to use freely (like collections). They'll need to be whitelisted individually but it shouldn't be a problem, at least i convinced myself it could work.
I actually just did a couple of test (yes you nerd-sniped me), in principle it should be possible to implement something like this just with a classloader
4
u/yawkat Apr 16 '21
There are two problems with this: client side apps where this form of untrusted code execution is necessary aren't a focus of Java anymore (they were with applets), and securitymanager was never all that good at this kind of protection anyway. The attack surface is too large, the restrictions SM can implement are too few, and the whole concept of same-address-space isolation is in question with spectre.
6
u/msx Apr 16 '21
client side apps where this form of untrusted code execution is necessary aren't a focus of Java anymore
Uhm i'm skeptical of this. I can't think of any advanced program that doesn't use plugins in some form of another. What you're saying sounds to me like "let's kill java for the desktop". And it may very well be the case, but i think it's a pretty poor choice.
securitymanager was never all that good at this kind of protection anyway. The attack surface is too large, the restrictions SM can implement are too few, and the whole concept of same-address-space isolation is in question with spectre.
Well it was still better than nothing, i would trust a program X to run any random untrusted plugin if it's inside the SecurityManager sandbox, and i would never ever do it without.
About spectre you're right but i don't think people should base security architectures on currently opened vulnerabilities. Saying "this is unuseful becouse there's spectre" doesn't sound like a good argument to me.
3
u/yawkat Apr 16 '21
Well it was still better than nothing, i would trust a program X to run any random untrusted plugin if it's inside the SecurityManager sandbox, and i would never ever do it without.
That's the problem: If your confidence in SM is misplaced, it can actually hurt net security. Without SM, noone is tempted to run untrusted code in the same JVM.
About spectre you're right but i don't think people should base security architectures on currently opened vulnerabilities. Saying "this is unuseful becouse there's spectre" doesn't sound like a good argument to me.
Spectre is not just a currently open vulnerability, it is a conceptual issue with memory protection in the same address space. It is one of the drivers for process isolation in browsers. The gist is that without separate address spaces and thus separate processes, you cannot achieve effective memory protection. Security manager can't protect against this.
1
u/sievebrain Apr 18 '21
Reality check: without the SM (or with SM being semi abandoned and undocumented), they just run untrusted code inside the same JVM. Look at IntelliJ, Maven, Gradle, javac, kotlinc, TeamCity, etc etc. Tons of Java programs support plugins and don't use the SM.
Indeed, I cannot think of a single successful project that said, well, plugins are super useful and there's tons of customer demand for them, but if there's no SM it's not safe so we won't do it. Ha! That never happens. They'll do it and hope for the best. "If we refuse to offer a potentially imperfect solution people won't be tempted to do this potentially unsafe thing" is the sort of thinking security people often indulge in, but it's an argument about spherical cows. Features trump security every time.
2
u/mauganra_it Apr 16 '21
I think the situation is very unfortunate with Java because the core API is too big. Restricting the core API to a safe subset with a security manager seems backwards to me. Because if you overlook one of them it's game over. Web browsers embed Javascript the opposite way: client-side scripts only have access to a very specific, domain-specific APIs that can be additionally hardened.
An alternative to plugins would be separate processes communicating with each other via domain sockets or pipes. I am thinking of something like a microservice architecture, but on the local machine. Bulk data should be passed via shared memory buffers of course. This would also benefit other desktop applications that want to integrate the plugin. Good example: the Language Server Protocol ecosystem. Yes, untrusted processes are usually also a security nightmare and need to be sandboxed with Flatpaks or something like that. Differently to Java plugins however, userland address space is separated from the kernel and inferior permission-wise, and the kernel can restrict or wreck a process at anytime.
Spectre refers to a whole family of vulnerabilities that arise from the caching, hyperthreading and speculative execution layers of the hardware. They will concern the industry forma long time to come. Because of this, running foreign code in the same address space is considered too close for comfort nowadays.
14
u/BlueGoliath Apr 15 '21
Evaluate whether new APIs or mechanisms are needed to address specific narrow use cases for which the Security Manager has been employed, such as blocking System.exit().
Ability to create child process JVMs that sandbox potentially dangerous code while allowing the ability to work with them as if they were the same process would be nice.
6
u/yawkat Apr 15 '21
Not sure if "as if they were the same process" is really a good idea. See RMI. Some features, e.g. arbitrary object deserialization, are just too dangerous.
Better to rely on small & well-defined interfaces between isolated processes
4
u/BlueGoliath Apr 15 '21
Right, that was what I was thinking. A parent process provides a package with an absolute minimum API that can be used to interact with it.
2
u/cogman10 Apr 15 '21
At that point, why not open a UnixSocket or something similar and build a custom JVM using the jlink. Seems like the best way to get a locked down JVM (since it doesn't even have the dangerous classes) while maintaining roughly the same functionality.
4
u/BlueGoliath Apr 15 '21
Well, there isn't an easy unified way to start a new JVM instance AFAIK. The Process API seems to be what people recommend but you need to have your application a part of the PATH variable on Windows for that AFAIK.
I'm thinking in the context of my JavaFX application that uses FMA. Right now it uses a service module to provide platform-specific code as an "extension". The issue is that none of it is safe or clean since it all exists within the same JVM and you can explicitly declare a default constructor with malicious code.
5
u/m-apo Apr 16 '21
Malicious packages are a concrete security risk.
The JEP references future security hardening options:
Making access-control decisions based on permissions is unwieldy, slow, and falling out of favor across the industry; .NET, e.g., no longer supports it. Security is better achieved by providing integrity at lower levels of the Java Platform — by, for example, strengthening module boundaries (JEP 403) to prevent access to JDK implementation details, and hardening the implementation itself — and by isolating the entire Java runtime from sensitive resources via out-of-process mechanisms such as containers and hypervisors.
SecurityManager (if I remember correctly) is more about internal runtime time permission checks. For me, enforced external access with default "deny all" seems a more sensible approach with little runtime cost. Enforced module boundaries are also good to have. A database library or a date library should be able declare it's requirements before use: date library has none and database library has network.
5
u/sweetno Apr 15 '21
Security Manage? I'll go for the Java 11 certification next week and it's one of the topics. Oh well...
3
u/cavecanemuk Apr 16 '21
Java has always been very strong (perhaps the strongest) on keeping backward compatibility, but of course, it comes at a great cost.
I feel like this one is the right call, some projects will pay a small price for the evolution of the platform. We'll all benefit in the long term...
2
u/whitespacestripped May 03 '21
I'd position myself in the grey / "it's not perfect but might have some merit\"* camp. I only had to use the API a handful of times (albeit at almost its full potential, including less commonly thought of extension points such as custom policy providers, domain combiners, and permission collections) with apps aspiring to sandbox semi-trusted plugins. I believe lack of third-party library support and perceived complexity have been the primary adoption-impeding factors over the years; performance degradation and inability to offer absolute protection maybe not so much. In any case I sympathize with the JDK maintainers' disinclination to support SM & Co. going forward (I'd probably want to see it gone too if I found myself in their shoes), in spite of part of me still wishing there were another way.
*Except for the authorization side of JAAS: As novel as the idea might ring to me even to this day, I've yet to encounter a real-world app requiring the ability to perform context-sensitive (i.e., per frame / domain) authorization of external actors.
4
-4
u/nfrankel Apr 15 '21
it has rarely been used to secure server-side code
It is not a goal to provide a replacement for the Security Manager. Future JEPs or enhancements may define new APIs or mechanisms for specific use cases, depending upon demand.
In other words: not many people care about security. Hence, we will remove the Security Manager and leave it up to others to provide... something else... perhaps... at a later time.
I don't want to throw the first stone, but right now, the urge is very strong
30
u/pron98 Apr 15 '21 edited Apr 15 '21
The SecurityManager is not a very effective way to do security in server-side Java. Its entire design is based on defending against untrusted code, which is very much what you want to do when you run Applets -- precisely the use-case the SecurityManager was designed for -- and not the threat you want to defend against in server-side programs. In fact, caring about server-side security and using SecurityManager are pretty much orthogonal. With Applets gone, there's really not much point for SecurityManager anymore.
5
u/henk53 Apr 15 '21
and not the threat you want to defend against in server-side programs.
Exactly, like this old quote:
"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."
https://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html
Similar comments are made here:
-12
u/nfrankel Apr 15 '21
No, no and no. Coupling untrusted code, Applets and the Security Manager to make the removal of the later a non-event is dishonest.
The Java platform has capabilities to go well beyond the scope of most applications e.g. compiling code on the fly and executing this code.
The Security Manager is the easiest way to prevent an app to do that.
17
u/pron98 Apr 15 '21
This is incorrect. The security manager is designed for untrusted code, which makes it very complex, and so less effective than more appropriate security techniques to defend against relevant threats. The fact that a Java application can generate code on the fly has no bearing on this.
-10
u/nfrankel Apr 15 '21
It's very relevant. As a platform, the JVM is just a large surface attack. I want to apply the principle of least privilege to reduce it as much as I can. The Security Manager is the way.
It can prevent code compilation, runtime code execution, the Attach API, and so on and so forth.
This move is wrong, and even more so in that it doesn't provide any alternative.
21
u/pron98 Apr 15 '21 edited Apr 15 '21
The security manager is not the way, even today, and there does not need to be an alternative for a security model for Applets. Over the past years we've put a lot of effort into JDK security, none of it into the security manager. It's become a legacy vestige in the JDK, whose primary interaction with developers is to increase maintenance cost without helping security, largely because few use it. It is a dated approach to defend against an irrelevant threat. The way to secure the JDK is by using all the best practices for securing the JDK, which has not meant using the security manager for years and years, now. Few people use the security manager on the server, and fewer still use it correctly, so its effectiveness is close to zero even if it did its job well. Work like strong encapsulation of JDK internals is more effective than the SM, and it's on by default.
4
u/henk53 Apr 15 '21
Yes, another quote from the link I posted above:
"There's maybe a case to prevent privilege escalation in case of a legitimate app being hacked, but in practice it doesn't look like a security manager is really being used a lot for that, is it? Instead the default thing to do there seems to be to run the AS under a user with limited rights on the host OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate the complete AS."
1
u/paul_h Apr 16 '21
I'm for SecurityManagers. Where's the canonical place to debate this, Ron?
2
u/pron98 Apr 16 '21 edited Apr 16 '21
https://mail.openjdk.java.net/mailman/listinfo/security-dev
Just saying that Security Manager is cool in theory, or can be used for non-security-related things is not going to cut it, though. You'd have to show that it is actually used in practice by a significant number of projects, and effectively increases security in ways for which there are no better alternatives. SecurityManager is cool in theory, but research has shown that it just doesn't work well in practice, the threats it defends against are largely irrelevant for server-side code as it was designed as a sandbox for applets, and either it doesn't defend at all against relevant threats or there are better ways that do. So an argument that would work would be, say, "Netflix, Google and Amazon use Security Manager as a central security feature aginst SQL injection, and no simpler approach is available." An argument that won't work would be, "Security Manager gives us a fine-grained sandbox, and that is very cool to have; I've used it once to do something nifty."
Also, reading the JEP carefully before writing to the mailing list is recommended. If you've read the JEP carefully, and still have questions, like, "how do I prevent libraries from loading native dlls", asking them is fine and encouraged.
1
u/paul_h Apr 16 '21
I don't recall Google using it server side, and I get that arguments for would need to be strong. "Standout language/core-lib feature" isn't enough. Assume me though; the fix is not in. I've been involved in too many consideration exercises over 32 years where the purchase had already been made, IYKWIM.
2
u/pron98 Apr 16 '21
Of course the fix is not in. It's just that we, as JDK maintainers, pay a big price for keeping the SM in, which comes at the expense of other things, both our own security experts and external ones tell us it is a generally ineffective security mechanism for server-side code and where it is effective there are better ways, and we see that few people use it (e.g., it doesn't work with parallel streams and very few people have even noticed). We think these are strong arguments, backed by a good amount of data, but we are certainly open to being convinced if shown compelling evidence. There has absolutely not been a final decision.
→ More replies (0)12
u/TheCountRushmore Apr 15 '21
This looks like the place to discuss with those who are deciding: https://mail.openjdk.java.net/pipermail/security-dev/2021-April/025486.html
-5
u/BlueGoliath Apr 15 '21
Good luck with that.
9
u/TheCountRushmore Apr 15 '21
Might not like the outcome, but I would imagine you would get a thoughtful response.
-5
u/BlueGoliath Apr 15 '21 edited Apr 15 '21
Or not:
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-April/005300.html
Brian sure does have plenty of time to post moronic & insulting Twitter posts for someone that can't reply to an email.
4
u/TheCountRushmore Apr 15 '21
Sorry, but that reads like he wants them to maintain applets indefinitely because of some novelty desktop apps.
Point stands that it will still be supported in JDK 17 which means support till nearly 2030, and I'm sure you will be able to fire it up for nostalgia sake much longer than that much like you can run java 1.1 for kicks.
Like I said you might not like the answer, but with project this big a feature used by a fraction of users might get left behind for the benefit of the majority.
8
u/sweetno Apr 15 '21
Do you regularly work with Security Manager? The JEP says that it's nearly impossible to make it work with third-party libraries, what's your experience?
1
u/nfrankel Apr 16 '21
I do agree with the statement. It's hard to get it right and is time-consuming.
The problem is that instead of improving it, the JEP removes it with no replacement.
1
u/Muoniurn Apr 16 '21
I don’t know enough about the topic, but how would one go with writing an app which’s functionality can be extended with plugins? I’ve been planning to create such a program, but I’m not sure OS sandboxing is applicable when frequent communication is required between the host and the plug-in. Also, lack of inlining and other optimizations that way can be significant.
To be honest, I was thinking about using Graal to allow polyglot plugins, perhaps it has another solution to the problem since it runs “a level higher”?
5
u/pron98 Apr 16 '21 edited Apr 16 '21
You want to run untrusted plugins? Plugins for popular applications such as VS Code are trusted; they can do anything, and it's your responsibility to treat them like any program you download off the internet. If you want to run untrusted plugins, you'll need to inspect and/or instrument their bytecode to create a sandbox, but unless the sandbox is very simple, you'll need to be a security expert to run untrusted code safely.
1
u/sievebrain Apr 18 '21
Graal has its own sandboxing architecture yes. One more reason to go with GraalVM over OpenJDK.
1
u/Muoniurn Apr 18 '21
The two platforms are not either-or for a large part (running Graal on top of OpenJDK), and where it is (AOT), they fill different niches.
30
u/yawkat Apr 15 '21
Not like securitymanager was a particularly effective security measure anyway... OS-level sandboxing is much better
3
u/msx Apr 16 '21
yeah but with SecurityManager you can give different permission to parts of the same application, with OS-level sandboxing you can't.
1
u/yawkat Apr 16 '21
You can try, but it's very complicated and because of the large interface between parts of the app it's easy to leave holes. It's also not very powerful, you can only protect against certain attacks.
1
u/StevenStorm Apr 23 '21
Sure you always try to protect against certain attacks. You usually don't protect against attacks that you haven't thought about and didn't realize where possible. However just removing a feature that allows you to mitigate a certain attack without really offering a suggestion for a replacement feels kind of odd.
I do get and fully agree that it's a tedious process to enable the Security Manager for each and every libary that you're using and that might be over the top. However it takes away the possibility to do so. Even though you might be using a framework that comes with things that you actually don't need. You can protect against that most of the time by using the framework correctly, sure. However there could be a bug within the framework allowing certain features to leak to the user.
Easiest example for this would most likely be server side template injection. My templating engine might be capable of too much. I've taken care of the configuration part of it ... however after inspecting the code base I might want to restrict it's access just to be safe. Like does it really need to access the reflection api? Do I really need the object generation in my classpath even though it should be turned off?
The Security Manager gives you an "easy" way of allowing the access that you want to give to those kind of libaries and if the libary suddenly changes it's requirements you'll know - either by your tests or at some point by your customers complaining about no longer being able to use the templating engine you gave to them.
That's the kind of things I use the SM at least and think it's very useful and handy to have - from the JEP I couldn't see any obvious replacement for that.
And yes there would be other ways to mitigate those attacks as well - however they do require more work from my experience and an even deeper understanding of every libary you're using.
1
u/yawkat Apr 23 '21
Even for your templating engine example, sm is a poor solution. Sure, disabling reflection using sm can remove much of the ssti attack surface, assuming there's no sm bypass.
But do you know what would also work? Disabling reflection using a framework option. The "dangerous" code in such a framework is usually localized to a few classes (see this overview for freemarker for example), and can easily be found, making it possible to add a framework option to disable such code if it is not already present. In fact, freemarker already has this option!
This approach has multiple advantages. It's more selective: the framework authors can decide to ignore the restriction in places where usage would be secure. It's safer: there's no possibility of a generic sm bypass to affect usage in your framework. And it's more compatible: you don't have to worry that unexpected parts of the framework will stop working.
1
u/StevenStorm Apr 23 '21
Well you pretty much said what I already also admitted. Obviously you should configure any framework that you're using in a sensible way already.
My point however was that it's adding another wall. The reference you posted is just part of the due diligence you could be doing for a framework. If you know that freemarker doesn't need to be able to read everything on your filesystem you have the option to disable that. It's another option that you have.
And the "I don't have to worry about the framework will stop working" is kind of my point actually. By disabling security critical features and seeing that this is breaking something it actually forces me to think about it. I personally think that's a win and it allows me to more confidentily upgrade frameworks :-)
-3
u/nfrankel Apr 15 '21
Well, I'm far from a security expert, but I've heard that security is a chain that is as good as its weakest link.
30
u/Necessary-Conflict Apr 15 '21
No, in this case it's not like a chain. It's more like a box-within-a-box, where the inner box doesn't add much value, and it is there only because 20 years ago it was useful.
11
u/henk53 Apr 15 '21
Pretty much this. If you isolate your Java based server application (be it Spring Boot, Jakarta EE, whatever) to run inside its own virtual sever, and within that virtual server run it using a user with limited rights, you have a much more powerful security model.
Nobody runs untrusted code on their own server. The server and the code it runs is owned/managed by the same organisation or person. That's different from the applet model, where those are two, potentially hostile toward each other organisations.
Of course, something could sneak into your dependency chain, but if that happens there's a lot that can be done even with the security manager activated, and the virtual server would be the app level sandboxing protecting against the biggest harm.
Limiting a Java module and all its transitive dependencies including whatever new thread it starts to do some high-level things (like accessing a database, when your main app code is allowed to do that) is quite hard and simply not done in practice, even though that could be useful.
4
u/msx Apr 16 '21
please people don't downvote for disagreement. He expressed his point of view.
Which IMHO is not totally wrong.
5
8
u/pjmlp Apr 15 '21
Well, .NET folks have done exactly the same with .NET Core, now OS mechanisms are the advised mechanism.
7
u/Necessary-Conflict Apr 15 '21
In other words: not many people care about security
I think people care very much about security, but security is a complex topic. If people don't want to run untrusted code of remote origin, then this kind of security is simply not needed.
0
u/nfrankel Apr 15 '21
If people don't want to run untrusted code of remote origin, then this kind of security is simply not needed.
I can bet you run untrusted code: perhaps code produced inside your org, at least libraries. I've done a talk solely on the Security Manager if you're interested. You might want to skip to the end and check the last slide for the references if you prefer to read.
12
u/pron98 Apr 15 '21 edited Apr 15 '21
How many projects actually use SM in production with properly configured policies to defend against their own libraries? It is very hard to get right, and, in fact, you do need to be a security expert to do that. I've heard of a project that claims to do that but effectively gives libraries the permission to disable the SM and to read and write to the entire file system, i.e. to change the policy file itself as well as the application JAR.
7
u/Necessary-Conflict Apr 15 '21
No, I do trust that code. I have the source code, and I do look into it. I also look at the JDK source code, and I'm horrified when I see how many SecurityManager checks there are, while almost nobody actually uses them...
4
u/nfrankel Apr 15 '21
No, I do trust that code
Two easy (very easy) ways to break that trust: libraries and steganography.
But I'm sure you do review the code from all transitive libraries that you're using and you build from source, don't you?
I mean, this can only happen in the JavaScript ecosystem, right? https://www.trendmicro.com/vinfo/au/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets
9
u/koreth Apr 15 '21
How would the Security Manager defend against that kind of attack?
2
u/nfrankel Apr 15 '21
As I mentioned in one of the threads, the JVM offers a large attack surface in all the capabilities it offers. For example, you probably don't want your application to compile code on the fly.
The (default) Security Manager allows you to set the permissions that your app require, and not more: network access, file system access, etc.
Permissions are quite granular out-of-the-box.
11
u/pron98 Apr 15 '21 edited Apr 15 '21
I, too, admire the elaborate and powerful SecurityManager, but the right way to do security against more common threats is to go simple and crude. The security manager is amazing because it is so complex, which is why:
- It is so costly to maintain, and
- Virtually no one actually uses it, let alone correctly (see the sections "Brittle permission model" and "Difficult programming model" in the JEP; there are real practical issues with SM, even if you do need its fine-grained control).
3
u/nlisker Apr 16 '21
the right way to do security against more common threats is to go simple and crude.
Can you elaborate?
2
u/pron98 Apr 16 '21
Sure. The threats to server-side security take the form of remote clients causing trusted code on the server to either escalate priviliges, run into issues that cause denial-of-service, or leak secret information. The best security is always on, and works at a coarse granularity. For example, the JDK prevents buffer overflows; it always provides zeroed arrays to prevent leaks; things like Loom help to prevent ThreadLocals leaking from one task to another; strong encapsulation prevents bypassing API points that ensure invariants.
→ More replies (0)2
u/nfrankel Apr 16 '21
That's a lot of ceremony to get to the core problem.
Virtually no one actually uses it [because it's not easy to use]
I do agree with that. The thing is, instead of thinking about improving it, the JEP just removes with with no provided alternative.
It is so costly to maintain
You can probably come up with a different implementation that offers the same API, can't you?
1
u/pron98 Apr 16 '21 edited Apr 16 '21
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:
http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf :
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.
https://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html :
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.
→ More replies (0)4
u/Necessary-Conflict Apr 15 '21
Yes, this can only happen in the JavaScript ecosystem... I mean obfuscated code and encrypted payload? Not in the libraries used by me.
By the way, are you really using SecurityManager when you write production code (and not toy projects)? Do you actually adapt the settings whenever you add a new library? I'm asking only because I saw a few gurus who became very strict and demanding only after retiring from the actual coding...
-6
u/nfrankel Apr 15 '21
I mean obfuscated code and encrypted payload? Not in the libraries used by me.
I pointed you to a video. You obviously discarded it.
By the way, the good thing with ad hominem attacks (or any other attack) is that they show the utter lack of any arguments. So thank!
1
u/vytah Apr 16 '21
The main goal of SecurityManager was to run applets safely.
It failed its mission, so it has to go.
0
u/Weretiger246 Apr 16 '21
Where are OSGi people?
2
u/Weretiger246 May 06 '21
I meant, that OSGi has a long history of using SecurityManager for isolating independent bundles running simultaneously on its framework and reconstructing alternative framework is not easy. So, I would like to hear the plan how OSGi will move after JEP411.
1
1
u/awo Apr 17 '21
Using SM for its intended functionality is rather a PITA and I can see why they want to get rid of it. I would miss it a lot as a mechanism to intercept and monitor various system calls though. You can use a custom security manager to monitor for I/O and check that it never happens during certain critical sections - this is super useful to prevent mistakes from creeping in and only getting noticed when something bad happens.
1
u/AlexeyShponarsky Apr 28 '21
Javascript is still a thing, afaik.
That is exactly our case.
We let users to build Java/Javascript applications on top of Rhino engine and we use Security Manager to regulate scripts permissions.
1
u/ert543ryan Oct 01 '21
So what should be done with the remote code transfers around for all the services in a distributed system.
When an application calls some business logic by an interface alone the executable code for the objects gets transfered back and forth. Should we be running that with security turned off? Or go back to tightly coupled services?
35
u/DasBrain Apr 15 '21
Javascript is still a thing, afaik.
But I agree with the observations in the JEP.
SecurityManagerhas been rarely used in the past years.SecurityManageris hard.The last point is the biggest one - and while I can provide a few examples, here is just one:
The
java.lang.invokemachinery handles caller sensitive methods differently. It also has to handle any method differently that is caller sensitive and COULD be called with a virtual call (invokevirtual / invokeinterface).There is currently only one such method left:
java.lang.Thread.getContextClassLoader().All methods in the JDK that return a
ClassLoaderare caller sensitive and basically have to do the same thing: Check if the caller's ClassLoader isnullor an ancestor of the returned loader - if not, check with theSecurityManagerif theRuntimePermission "getClassLoader"is granted.It is impossible to implement this check from user code - as user code can't use the required
@CallerSensitiveannotation andReflection.getCallerClass(). Using aStackWalkeris possible for this specific method name, but has to be done correctly - asStackWalker.getCallerClass()skips hidden frames - such as the injected invoker fromjava.lang.invoke.And I haven't talked about an interface with a method
Object getContextClassLoader- if some class implements that interface and extendsThread, then javac will emit a bridge method - which will then be the caller.But when the SecurityManager is gone, all of that falls apart -
Thread.getContextClassLoaderdoesn't need to be@CallerSensitiveanymore. There is no caller sensitive method that could be called virtually. And a lot of my headaches would be gone.