4 ms·

None of that explains why java breaking tried and tested existing solutions is a good idea for anyone.

derefr 5y ago
Because nobody is maintaining it, because nobody is using it in big modern projects; and a blacklist-based solution like the Security Manager needs constant attention and maintenance as the JVM's stdlib grows, to avoid something slipping through. Every time someone adds something that needs to be secured to the JVM, there's the extra overhead of coming up with a (not necessarily easy!) way of instrumenting it for the Security Manager to control. Given a fixed pool of developer resources, eliminating unused per-change overheads like this, serves as a multiplier for the project's ability to do everything else. The time freed from core devs by not writing Security Manager instrumentation for everything, could be instead allocated to e.g. getting Project Loom stable and upstreamed. And that's assuming that everyone even does the Security Manager instrumentation of each new thing perfectly. The devs doing that instrumentation don't use Security Manager any more than a random Java dev does, so they likely don't know its ins and outs. Every new patch is thus a new opportunity for someone to bungle the Security Manager instrumentation, and thus for exploitable JVM surface area to be created. The more time that goes by, the more likely such exploitable surface area is to have already been introduced and gone entirely unnoticed by a population of developers that just doesn't use the feature. And so, the more time/patches that go by, the more that the Security Manager shifts from being a harmless thing to leave around, to a land-mine waiting to strike any dev who does try to use it. (The "blacklist where at any point a new feature could be added and its security implications missed" problem is the same reason it's hard to trust SELinux—but at least SELinux is used by default for securing system components in some Linux distros, so at least SELinux policies gets pulled in on a regular basis as part of other companies' security audits of their stacks. Security Manager isn't used by default anywhere!)

Because nobody is maintaining it, because nobody is using it in big modern projects; and a blacklist-based solution like the Security Manager needs constant attention and maintenance as the JVM's stdlib grows, to avoid something slipping through. Every time someone adds something that needs to be secured to the JVM, there's the extra overhead of coming up with a (not necessarily easy!) way of instrumenting it for the Security Manager to control. Given a fixed pool of developer resources, eliminating unused per-change overheads like this, serves as a multiplier for the project's ability to do everything else. The time freed from core devs by not writing Security Manager instrumentation for everything, could be instead allocated to e.g. getting Project Loom stable and upstreamed. And that's assuming that everyone even does the Security Manager instrumentation of each new thing perfectly. The devs doing that instrumentation don't use Security Manager any more than a random Java dev does, so they likely don't know its ins and outs. Every new patch is thus a new opportunity for someone to bungle the Security Manager instrumentation, and thus for exploitable JVM surface area to be created. The more time that goes by, the more likely such exploitable surface area is to have already been introduced and gone entirely unnoticed by a population of developers that just doesn't use the feature. And so, the more time/patches that go by, the more that the Security Manager shifts from being a harmless thing to leave around, to a land-mine waiting to strike any dev who does try to use it. (The "blacklist where at any point a new feature could be added and its security implications missed" problem is the same reason it's hard to trust SELinux—but at least SELinux is used by default for securing system components in some Linux distros, so at least SELinux policies gets pulled in on a regular basis as part of other companies' security audits of their stacks. Security Manager isn't used by default anywhere!)