<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=DE link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Hello Alan,</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>not sure if it is good or bad to make the security manager even less Mainstream (especially after there was a Project to reduce the Impact of security Manager). However, not diving into this discussion here :)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One thing which might be a problem: when doPrivileged does no longer execute the Code in a seperate stack this has implications to the runtime. The stacks will get deeper (and might even overflow (more often)). So maybe this „no seperate stack“ function should be opt-out (if implemented).</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Gruss</p><p class=MsoNormal>Bernd</p><p class=MsoNormal>-- <br>http://bernd.eckenfels.net</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Von: </b><a href="mailto:Alan.Bateman@oracle.com">Alan Bateman</a><br><b>Gesendet: </b>Montag, 20. November 2017 15:47<br><b>An: </b><a href="mailto:security-dev@openjdk.java.net">OpenJDK Dev list</a><br><b>Betreff: </b>Eliminating the security overhead when not running with a securitymanager</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One of the long standing issues with the security manager support is </p><p class=MsoNormal>that the overhead when there is no security manager is non-zero. Two </p><p class=MsoNormal>specific examples are (i) the overhead of defineClass (assuming the </p><p class=MsoNormal>defining loader is a SecureClassLoader) as it involves a callback to get </p><p class=MsoNormal>the permissions for the protection domain and (ii) the overhead of </p><p class=MsoNormal>AccessController.doPrivileged in order to execute an action on a </p><p class=MsoNormal>privileged stack.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The bigger question is of course whether it is interesting to run with a </p><p class=MsoNormal>security manager in 2017. It's clearly still important for environments </p><p class=MsoNormal>that download potentially malicious code to execute in a sandox but that </p><p class=MsoNormal>isn't most applications these days. We have seen a few cases where </p><p class=MsoNormal>applications set a security manager in order to enforce some policy, </p><p class=MsoNormal>like preventing plugins calling System.exit but these are cases that </p><p class=MsoNormal>would be better served with other solutions.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I would like to explore changes to the API and implementation that would </p><p class=MsoNormal>allow us to eliminate some of the overhead when not running with a </p><p class=MsoNormal>security manager. Long term then it would be interesting to explore </p><p class=MsoNormal>degrading and eventually dropping the security manager but that is </p><p class=MsoNormal>beyond the scope of what I would like to discuss here. Sean Mullan and </p><p class=MsoNormal>Jeff Nisewanger ran an interesting BOF at JavaOne 2017 on this topic and </p><p class=MsoNormal>I believe are planning to do a survey at some point to understand the </p><p class=MsoNormal>current usage of the security manager.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For now I would like to explore what it would take to eliminate some of </p><p class=MsoNormal>the overhead. A big challenge is the System.setSecurityManager API as </p><p class=MsoNormal>allows a security manager to be set in a running VM. This means that </p><p class=MsoNormal>classes loaded before a security manager is set may be involved in </p><p class=MsoNormal>permission checks that happen after a security manager is set. </p><p class=MsoNormal>Similarly, privileged actions may have started before the security </p><p class=MsoNormal>manager is set. The complications around this go away if there was some </p><p class=MsoNormal>way to know that a security manager can never be turned on in a running </p><p class=MsoNormal>system.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>To get started, I've put a prototype of an initial proposal on the cr </p><p class=MsoNormal>site [1]. The summary of the proposal is:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>1. A "disallow security manager" mode that is opt-in to disallow </p><p class=MsoNormal>setSecurityManager being used to set a security manager in a running VM. </p><p class=MsoNormal>Opt-in means it has not impact on existing code.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>2. Deprecates setSecurityManager to discourage further usage and allow </p><p class=MsoNormal>for the possibility of making "disallow security manager" the default in </p><p class=MsoNormal>the future. If that were to become the default then it would have no </p><p class=MsoNormal>impact on deployments that set the security manager on the command line </p><p class=MsoNormal>at startup.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>3. When running in "disallow security manager" mode, </p><p class=MsoNormal>AccessController.doPrivileged invokes actions directly and </p><p class=MsoNormal>SecureClassLoader.defineClass skips the callback to get permissions for </p><p class=MsoNormal>the protection domain. This part helps startup and runtime performance.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It's important not to get hung up on the details in the webrev, the </p><p class=MsoNormal>important thing is understand if the security folks on this mailing list </p><p class=MsoNormal>are open to a run mode that prevents a security manager being set in a </p><p class=MsoNormal>running system.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Alan.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[1] http://cr.openjdk.java.net/~alanb/8191053/webrev/</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>