0

The java-security-manager-deprecation not withstanding JEP-411 (Deprecate the Security Manager for Removal), would enabling sandbox mechanism by leveraging the java security-manager (and associated class-loading mechanisms) be a good approach?

As I understand it (and mentioned in the JEP-411 as well), they were originally intended to do just that - keep applets from running rogue code.

So the most reliable technique, spanning across libraries (since the same vulnerability can be introduced theoretically in any open-source library), would be to enable the sandbox mechanism ?

This way the remote code would end up being loaded from the temp-dir or some non-approved location. Thus it would help keep applications safe inherently rather than rely on external mechanisms to protect the application.

Is my understanding correct ?

Ravindra HV
  • 2,558
  • 1
  • 17
  • 26
  • The security manager filters the calls the managed code can make to the rest of the VM. Some are allowed, some are denied. The concept failed on the denied set being impossible to define even for a somewhat clear use case like applets so that people would not be able to break out of it. A logging library has no business loading remote code in the first place. Filter or not. I imagine a crypto miner could limit its external calls to some innocuous minimum. I still don't want to be running it. –  Jan 19 '22 at 22:36
  • Blacklisting would be exhaustive for any design (Eg: firewall rules). If SecurityManager approach could work by validating the whitelisted rules, then so much the better as opposed to not having any which would be the case going forward. Deprecating a security machanism without a replacement seems to have been from an I'll advised thought process, atleast in retrospect. – Ravindra HV Jan 20 '22 at 21:00

1 Answers1

-1

Note - As per the original JEP-411 entry, the approach to securing environment is by alternate means, including and not limited to - use of containers !

Ravindra HV
  • 2,558
  • 1
  • 17
  • 26