4 ms·
Not long after log4shell yet another example of why JEP 411 (removal of SecurityManager) is a very questionable decision. Running applications under SecurityMa
by mkleczek 4y ago
Not long after log4shell yet another example of why JEP 411 (removal of SecurityManager) is a very questionable decision.
Running applications under SecurityManager would have prevented a lot of these vulnerabilities (or rather - their severity would be much lower).
- planb 4y agoWhy? You still get full access to everything the app can see - all Confluence content. To prevent access to the rest of the system, there are better ways now (Containers). YMMV, but SecurityManager was never really usable in most real word use cases.
- dx034 4y agoTo be fair, with most stuff running as VMs, a confluence server will usually not run anything else. So root doesn't really change much here I guess.
- Chyzwar 4y agoVM might have access to more cloud resources via bad AIM policies. Getting access to root even in container can be just as bad.
- mkleczek 4y ago> You still get full access to everything the app can see - all Confluence content. No (with proper policy in place). That's the whole point of SecurityManager. Even if you can execute code - it is sandboxed and has limited (or none at all) permissions.
- bzzzt 4y agoWhy is removing a legacy component which is effectively ignored and unusable by most modern applications an issue? SecurityManager is very fine-grained so you have to spec out every file access by your application (including those of third party code you may or may not know about). Most server side Java deployments run without it so you're better off making sure the permissions of the server process are correct than customising the Java policy.