<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">> The <span class="gmail-il">security</span> <span class="gmail-il">manager</span> is legacy these days and I think we need to figure out a plan how to deprecate and eventually bury it.</div><div dir="ltr"><br></div><div dir="ltr">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.   <br></div><div dir="ltr"><br></div><div>I went through two sample projects and found a way to use Byte Buddy to disable SecurityManager so that it could not be disabled:</div><div dir="ltr"><br></div><div dir="ltr"><a href="https://tersesystems.com/blog/2015/12/22/an-easy-way-to-secure-java-applications/">https://tersesystems.com/blog/2015/12/22/an-easy-way-to-secure-java-applications/</a><br><div><br></div><div><a href="https://tersesystems.com/blog/2015/12/29/sandbox-experiment/">https://tersesystems.com/blog/2015/12/29/sandbox-experiment/</a><br></div><div><br></div><div><a href="https://github.com/johnlcox/sandbox-runtime">https://github.com/johnlcox/sandbox-runtime</a><br></div><div><br></div><div>If there is a way to do this without involving the security manager that would be great -- likewise, if there's any docs on how it's just not up to the task, that would be good too.</div><div><br></div><div>Thanks,</div><div>Will Sargent.</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 14, 2018 at 6:22 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14/09/2018 13:46, David Lloyd wrote:<br>
> :<br>
>> There are essentially two main parts to this change:<br>
>><br>
>> 1. Deprecation of System.s[etS]ecurityManager()<br>
> We (JBoss) use this method to configure some things at run time (like<br>
> customizing the Policy) before installing our security manager, so<br>
> this would be not so great for us.<br>
The security manager is legacy these days and I think we need to figure <br>
out a plan how to deprecate and eventually bury it. I have no idea how <br>
many releases or years that might take but the proposal here is a <br>
profitable first step. It's easy to imagine follow on steps where the <br>
default changes to not support the security manager without some opt-in. <br>
Yes, this will be disruptive for a number of usages but there is lots of <br>
time to look for solutions to the issues that people are using the <br>
security manager for today - for example we've seen several cases where <br>
people set a security manager because they lack hooks to prevent plugins <br>
from doing things (plugins or tests calling System.exit comes up <br>
periodically for example).<br>
<br>
-Alan<br>
</blockquote></div>