<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Peter Firmstone" <peter.firmstone@zeus.net.au><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr>, "Alan Bateman" <Alan.Bateman@oracle.com><br><b>Cc: </b>"jdk-dev" <jdk-dev@openjdk.java.net>, "security-dev" <security-dev@openjdk.java.net><br><b>Sent: </b>Wednesday, July 28, 2021 1:12:32 AM<br><b>Subject: </b>Re: How to remove the SecurityManager<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><p>Thanks Remi,</p>
<p>Sand-boxing is a bad idea, we are in agreement, it's not
something we do, personally I'm taking an interest in safer
languages, eg Haskell on secure platforms, eg OpenBSD on Sparc64
*.</p>
<p>Perhaps JEP 411 is simply a reflection on the evolution of
languages. Java was safer than C and C++ so replaced these,
something safer again will replace Java.</p></blockquote><div><br></div><div>All mainstream languages have a way to access to raw pointers to be able to call C functions,<br data-mce-bogus="1"></div><div>here is the one in Haskell<br data-mce-bogus="1"></div><div>https://hackage.haskell.org/package/base-4.5.0.0/docs/Foreign-Storable.html<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><p><br>
</p>
<p>I think people are getting our primary use case, authorization,
confused with sandboxing (not on our use case list). OpenJDK
developers provided a Sandbox example, I just wanted to
communicate that I didn't think it was a practical defense against
exploits, nor applicable to our use case:</p>
<p><a href="https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/" target="_blank" rel="nofollow noopener noreferrer">https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/</a><br data-mce-bogus="1"></p>
<p>Our process for establishing whether third party libraries are
trusted before we use them:</p>
<ol><li>Build dependency check using Owasp
<a href="https://owasp.org/www-project-dependency-check/" target="_blank" rel="nofollow noopener noreferrer">https://owasp.org/www-project-dependency-check/</a> Reject any
dependencies that fail, see
<a href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml</a>
line 87 for an example of a disabled module due to a
vulnerability in a dependency, the module will only be
re-enabled if the vulnerability is fixed.<br>
</li><li>Static analysis using SpotBugs, then review identified bugs,
review source code if available. Reject if security bugs are
present, or fix / patch.<br>
</li><li>Profiling of permission access checks using:
<a href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java</a><br data-mce-bogus="1"></li><li>Reviewing generated policy files, using grep, this example was
generated from over 2000 tests:
<a href="https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new</a><br data-mce-bogus="1"></li><li>Remove any permission from the policy file you don't want to
grant to third party code, if safe to do so, eg usage statistics
reporting.<br>
</li></ol>
<p>One of my use cases for SM is for auditing to establish trust,
and then using SM with POLP policy files generated following the
audit, to turn off JVM features we're not using. Our policy
provider is performant and high scaling even with policy files
containing 1000's of lines:
<a href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java</a><br>
</p>
<p>Our use of SM for access decisions occurs during and after
authentication, but also defines access roles for trusted parties,
it's not possible to replace SM authorization layer functionality
(not to be confused with sandboxes). Our use case is distributed
systems, with trusted services and trusted clients, which have
POJO proxy's, different service proxies are given different
ProtectionDomain identity and these identities are used for
authorization decisions. <br>
</p>
<p>In a simple Client - Server application, you only have one user,
from the client and the thread runs with this permission, but our
systems might be performing a transaction, with 5 different
services, and the transaction service is the client of these 5
services, which are represented by their proxy
ProtectionDomain's. If one of the authenticated services is not
authorized to participate in the transaction (eg a third party
that's not on the contract, or maybe the contract expired), then
it's not authorized and the transaction will fail. This all
occurs over secure authenticated connections, where both servers
and clients are authenticated, who's the server and who's the
client, well that gets a little blurred sometimes.<br>
</p>
<p><a href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java</a><br>
</p>
<p>Back in the Jini days, Sun Microsystems, allowed different
service proxy's to be loaded by the same ClassLoader, if they had
the same CodeSource, they had the same identity if they had the
same parent ClassLoader, we don't do that, ClassLoader's are
assigned to a service proxy, based on it's authenticated identity.</p>
<p><a href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java</a><br data-mce-bogus="1"></p>
<p>This system, at its foundations is based on Jini Extensible
Remote Invocation (JERI), we've replaced the serialization layer,
to use what we term atomic serialization and apply constraints
during connection establishment over secure connections.</p>
<a href="https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint" target="_blank" rel="nofollow noopener noreferrer">https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint</a><br>
<p> We limit access based on both the service and user identity. We
generate our policy files by profiling (the tool creates a policy
file with correct syntax, ready for immediate use), we recently
added replacement of local file paths with properties for policy
property expansion with cross platform trans-portability. While
its possible to use a dynamic proxy without downloading code, via
an atomic serialization connection, it's not generally advised to
do so with unauthenticated users, decisions around dynamic
discovery, whether class loading or downloads are allowed, it's
all based on policy decisions.</p>
<p>The problem with our software is its designed to operate on
un-trusted networks, and SM infrastructure is involved in
authorization decisions during the authentication process, as well
as providing user credentials for secure connections.</p>
<p>We have no future Java migration path after JEP 411, the
decision's been made, time to move on...</p>
<p>On the bright side, according the JEP 411, we did achieve what
OpenJDK dev's thought to be almost impossible. :) I'm pretty
sure using the process I've documented above, you will identify
99% of accidental vulnerabilities in local code, and that was good
enough for me lol.<br>
</p>
<p>
</p><blockquote>The threat of accidental vulnerabilities
in local code is almost impossible to address with the Security
Manager.</blockquote></blockquote><div><br></div><div>In your validation process, you have a static part to check the dependencies + SpotBug and a runtime part using a combination of class loader + security manager.<br></div><div>For the runtime part, instead of using classloaders, you can use an agent, it will also see all the requests to load a class, it can then do a static analysis of the bytecode to determine if the bytecode only contains kosher method calls and field access, the same way SpotBug does.<br></div><div>If you really want to have a mechanism that authorize some method calls or not at runtime, you can change the bytecode to introduce a method call that checks the security policy just before the authorizable method call/field access<br></div><div>(you also have to blacklist java.lang.reflect and java.lang.invoke but i supppose you already do this).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>This approach is better than using a classloader + security manager because</div><div>- Java allows you to define classes not linked to a classloader since Java 8 (the old API is Unsafe.defineAnonymousClass(), the new one is Lookup.defineHiddenClass()) <br data-mce-bogus="1"></div><div>- you can check any calls not only the ones that the SecurityManager traps.<br data-mce-bogus="1"></div><div>- you can reject calls before loading the class, so earlier than with a SecurityManager, more like the bytecode verifier does.<br data-mce-bogus="1"></div><div>- it's more lightweight in term of memory usage because it does not rely on ClassLoaders (each ClassLoader has its own metaspace, so a lot of CL fragment the memory a lot).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>To read and transform the bytecode, you can ASM [1], this is one of the library used by SpotBug to read/check the bytecode.<br data-mce-bogus="1"></div><div>(disclaimer: i'm one of the maintainer of that library).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>It's still not 100% perfect because the agent runs in the same process as the code.<br data-mce-bogus="1"></div><div>(you can go deeper by having the authorization framework in a VM puppeteering a client VM likes jshell does using JVMTI).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<br>
<p>* OpenBSD on Sparc (very well supported, Oracle should sell these
lol, the only drawback is no zfs) is a good idea, no Spectre or
Meltdown vulnerabilities.</p>
<p>buffy$ uname -a<br>
OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64</p>
<p>Although this one's a couple of versions behind, time for an
upgrade.</p>
<p>Regards,</p>
<p>Peter.</p></blockquote><div><br></div><div>regards,<br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>[1] https://asm.ow2.io/<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><p><br>
</p>
<div class="moz-cite-prefix">On 28/07/2021 5:52 am,
<a href="mailto:forax@univ-mlv.fr" target="_blank" rel="nofollow noopener noreferrer">forax@univ-mlv.fr</a> wrote:<br>
</div>
<blockquote>
<pre class="moz-quote-pre">----- Original Message -----
</pre>
<blockquote>
<pre class="moz-quote-pre">From: "Alan Bateman" <a href="mailto:Alan.Bateman@oracle.com" target="_blank" rel="nofollow noopener noreferrer"><Alan.Bateman@oracle.com></a>
To: "Remi Forax" <a href="mailto:forax@univ-mlv.fr" target="_blank" rel="nofollow noopener noreferrer"><forax@univ-mlv.fr></a>, "Peter Firmstone" <a href="mailto:peter.firmstone@zeus.net.au" target="_blank" rel="nofollow noopener noreferrer"><peter.firmstone@zeus.net.au></a>
Sent: Tuesday, July 27, 2021 6:33:25 PM
Subject: Re: How to remove the SecurityManager
</pre>
</blockquote>
<blockquote>
<pre class="moz-quote-pre">On 27/07/2021 17:11, Remi Forax wrote:
</pre>
<blockquote>
<pre class="moz-quote-pre">Peter, this is how you remove the security manager using the jdk 17 (the
SystemMirror class is specific to a JDK version).
Any in-process security measures fail if the API let you to peek and poke the
memory like Unsafe does.
</pre>
</blockquote>
<pre class="moz-quote-pre">I hope you aren't really suggesting anyone does this :-)
</pre>
</blockquote>
<pre class="moz-quote-pre">nope, it's a small example to explain why in-process sandboxing is a bad idea.
</pre>
<blockquote>
<pre class="moz-quote-pre">It's dependent
on the field layout so can break and crash the VM if it doesn't match.
Also it assumes that someone gets theUnsafe before a SM is set.
</pre>
</blockquote>
<pre class="moz-quote-pre">yes, it's just an example, you have infinite variations using JNI/JNA/JNR or panama and changing some field value.
</pre>
<blockquote>
<pre class="moz-quote-pre">-Alan
</pre>
</blockquote>
<pre class="moz-quote-pre">Rémi
</pre>
</blockquote>
<br></blockquote></div></div></body></html>