On Sun, Sep 16, 2018 at 2:38 PM Will Sargent <will.sarg...@gmail.com> wrote: > > > The security manager is legacy these days and I think we need to figure out > > a plan how to deprecate and eventually bury it. > > I don't know of any research or papers that explicitly say that > SecurityManager is "legacy". I did some research into this a while ago, and > while SecurityManager has some major flaws, I don't know of any other way to > sandbox a Java application.
Another interesting point is that, when it comes to the actual work of sandboxing, all of the difficult work is done by AccessController and AccessControlContext. However it's difficult to say that these should be legacy without addressing the problem of JAAS, which also uses these constructs to pass and check the current Subject. This aspect of JAAS seems to be known to be inherently defective by several (perhaps most) application server vendors, as those which use JAAS also tend to have a custom, thread-local-based solution for handling Subjects which is used in place of the ACC-attachment mechanism. With that in mind it's quite difficult to imagine a path that starts with deprecating SecurityManager and ends with its removal, unless JAAS is addressed. And if JAAS is successfully decoupled from AccessController, then maybe SecurityManager becomes a somewhat more viable technology again: based on some research I did a while back, it should be possible to reimplement it compatibly (and purely in Java) with less overhead and with more convenient constructs (once JAAS is out of the way). That said, the main security-oriented use of SecurityManager isn't around sandboxing fully untrusted code (since it cannot sandbox memory allocations or CPU usage), it's more about ensuring that your trusted code isn't inadvertently exploited, and (as Alan said) also occasionally about fencing in badly-behaved third-party code that (for whatever reason) cannot be modified. Though we've had AOP and similar technologies for quite a long time, as well as plenty of other frameworks that allow build-time and run-time bytecode rewriting, and it's not hard to argue that this is a better solution to this class of problem. Anyway I think that a better first move would have been to instead deal with the JAAS issue, one way or another. If this cannot be done, then the access controller is here to stay, and the security manager issue is moot. -- - DML
