<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Florian,</p>
<ol>
<li>If I fix that bug, will JEP 411 be cancelled? BTW. Sparc
isn't vulnerable.<br>
</li>
<li>My primary use case is for SM is for authorization decisions
for remote users and services.</li>
</ol>
<p>JSR-121: Java Application Isolation API Specification.</p>
<p><a class="moz-txt-link-freetext" href="http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html">http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html</a><br>
</p>
<p>People keep confusing isolation with authorization, these aren't
the same thing, Isolates were designed for Isolation, which never
made it into Java SE and AccessController was designed for
authorization access controls. Other access controls are part of
the language, such as public, private, protected modifiers etc.<br>
</p>
<p>Applets had a weak form of isolation using ClassLoader's, and had
permissions to connect to their originating network address. I
don't think anyone has developed Applets for at least 10 years?</p>
<p>I'm talking about currently maintained software that uses SM for
authorization decisions and am looking for ways to re-implement
authorization in JDK libraries using Agents.</p>
<p>Often constructors contain permission guard checks, but due to
finalizer defenses, these cannot be instrumented without
instrumenting private static methods. The alternative is to
instrument object methods instead, however these would impact
performance (although I'm considering instrumenting ClassLoader
object methods).</p>
<p>An example of a generated grant, note how the SHA-384 signature
of the file is captured, along with the User? This doesn't
include dynamically granted permissions which occur during
authorization, then downloading, class loading and unmarshalling
of a service proxy.</p>
<p>grant codebase
"httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd",<br>
principal javax.security.auth.x500.X500Principal
"CN=Outrigger"<br>
{<br>
permission org.apache.river.api.io.DeSerializationPermission
"MARSHALL";<br>
permission net.jini.security.AuthenticationPermission
"javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer
javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect";<br>
};</p>
<p>Without SM, everyone is authorized, our network connections will
allow everyone and anyone in, so I need to re-implement an
authorization layer, however OpenJDK has a monopoly on Java
libraries.</p>
<p>An alternative that isn't being considered at this stage is to
remove support for TLS and Kerberos connections from the JDK, and
use private virtual networks and a VM instead, however that stops
global service discovery over IPv6, and constrains the software in
many other areas as well, so it's not being considered at this
time.<br>
</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 2/08/2021 4:23 pm, Florian Weimer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8735rstle8.fsf@oldenburg.str.redhat.com">
<pre class="moz-quote-pre" wrap="">* Peter Firmstone:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">From our discussions, my interpretation is that OpenJDK is constrained
by corporate security policy; any issues with SecurityManager
infrastructure will be treated as confidential security issues and
have to be fixed with internal resources. Community volunteers won't
be allowed to handle them. Hence it's the maintenance burden. I see
this maintenance cost as a bureaucratic management issue, rather than
an issue with SM per se.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The dynamics would likely change if the community started fixing issues.
A starting point could be speculative execution vulnerabilities, which
are currently out of scope for the OpenJDK security process:
Java and Speculative Execution Vulnerabilities
<a class="moz-txt-link-rfc2396E" href="https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/000002.html"><https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/000002.html></a>
I think any use of the security manager for isolation purposes would
have to address those issues.
Thanks,
Florian
</pre>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>