Hacker News Reader

Comment by mkleczek | Hacker News Reader

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).

View on HN

Why? 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.

> 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.

To 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.

VM might have access to more cloud resources via bad AIM policies. Getting access to root even in container can be just as bad.

Why 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.

Reply on news.ycombinator.com