<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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.<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 class="moz-txt-link-freetext" href="https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/">https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/</a></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 class="moz-txt-link-freetext" href="https://owasp.org/www-project-dependency-check/">https://owasp.org/www-project-dependency-check/</a> Reject any
dependencies that fail, see
<a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml">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 class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java</a></li>
<li>Reviewing generated policy files, using grep, this example was
generated from over 2000 tests:
<a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new">https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new</a></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 class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java">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 class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java">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 class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java</a></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 class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint">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>
<blockquote type="cite">The threat of accidental vulnerabilities
in local code is almost impossible to address with the Security
Manager.</blockquote>
<br>
</p>
<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.<br>
</p>
<div class="moz-cite-prefix">On 28/07/2021 5:52 am,
<a class="moz-txt-link-abbreviated" href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2139489865.1124.1627415558046.JavaMail.zimbra@u-pem.fr">
<pre class="moz-quote-pre" wrap="">----- Original Message -----
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">From: "Alan Bateman" <a class="moz-txt-link-rfc2396E" href="mailto:Alan.Bateman@oracle.com"><Alan.Bateman@oracle.com></a>
To: "Remi Forax" <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a>, "Peter Firmstone" <a class="moz-txt-link-rfc2396E" href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a>
Sent: Tuesday, July 27, 2021 6:33:25 PM
Subject: Re: How to remove the SecurityManager
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 27/07/2021 17:11, Remi Forax wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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" wrap="">I hope you aren't really suggesting anyone does this :-)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
nope, it's a small example to explain why in-process sandboxing is a bad idea.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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" wrap="">
yes, it's just an example, you have infinite variations using JNI/JNA/JNR or panama and changing some field value.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
-Alan
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Rémi
</pre>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>