<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/05/2021 10:55 pm, Sean Mullan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com">-<br>
<blockquote type="cite">Obviously we won't have a call stack with
domains, I don't know how we will transfer the user Subject to
other threads, for TLS and Kerberos connections. No doubt
something is planned.
<br>
</blockquote>
<br>
There is a plan for preserving the capability to transfer Subjects
to other threads. It is described in the JEP:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://openjdk.java.net/jeps/411#Alternate-JAAS-APIs">https://openjdk.java.net/jeps/411#Alternate-JAAS-APIs</a>
<br>
<br>
--Sean
<br>
</blockquote>
<p><br>
</p>
<p>Thanks for the reference Sean.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com">
<br>
<blockquote type="cite">
<br>
Is the recommendation simply not to upgrade Java until new
access control API is developed?
<br>
<br>
<br>
<SNIP>
<br>
<blockquote type="cite">
<blockquote type="cite">Please provide some examples,
migration options suggestions will be appreciated.
<br>
</blockquote>
I’ve jotted down some thoughts in a blog post:
<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>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<p>Please read the following carefully and ask questions to clarify
if needed.<br>
</p>
<p>OpenJDK seems to have assumed that no one was using
SecurityManager based on one research report. There's a lot of
closed source java code out there, I suspect most of our users are
closed source. I don't know exactly how many compute nodes our
users have, but it's 100's to 1000's, we seldom hear from them,
maybe a patch here or there, then you don't hear from someone for
years, and then you receive a patch. These users don't advertise
they're using our systems either.<br>
</p>
<p>Some feedback, we preserve context within Executor threads.</p>
<p>AccessController scalability and performance is very good, we
carefully capture and re-establish security contexts in Executor
threads.<br>
</p>
<p>AccessController::getContext() is 0.5% of system load, with no
scalability issues.</p>
<p>AccessController::doPrivileged() is 2.3% of total cpu load, with
no scalability issues.</p>
<p>There are no other security calls on the list of hotspots,
unless you include Class.getProtectionDomain, which is 0.2%</p>
<p>Like I've mentioned previously, our policy provider is highly
scalable as is our SecurityManager implementation. Our policy
providers decorate functionality onto each other:<br>
</p>
<p><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></p>
<p><a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java</a><br>
</p>
<p><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/CombinerSecurityManager.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java</a><br>
</p>
<p>It's a shame that SecurityManager is crippled on Loom's virtual
threads, I was looking forward to using Loom for blocking network
connections. Oh well, scratch that Idea, we wouldn't be able to
make TLS connections with them. I was hoping Loom would reduce
memory consumption, but then I haven't read enough about it. We
consume a lot of threads, one of the thread factory's at least set
the thread memory to a lower value than default to save memory.
Is Loom is designed to run small rapidly completing non blocking
tasks?<br>
</p>
<p>The performance assumptions made by Ron only apply to the unloved
policy provider included with Java. The Sun file policy provider
implementation is a toy designed to get people started, no
tooling, no dynamic permission grants, it was really only there to
provide hooks for customization, applets maybe? Sorry, I have to
admit, I've never written an applet. The second constructor added
to ProtectionDomain in Java 1.4 added support for dynamic policy
grants, but it was not implemented by Policy file, it was done for
a reason however. I mean it was designed when Sun Sparc servers
had 4 to 8 CPU's, and x86 was 32 bit single cpu, unless you spent
big on Unix hardware. Sun policy file has only had some very
minor updates since, it has a blocking cache, yuck! <br>
</p>
<p>Our policy cache is immutable after publication. Mutable state is
not shared among threads in our policy providers. Our dynamic
grants are removed after the downloaded code is no longer
required, our dynamic policies are self populating and self
cleaning. They also operate under principles of least privilege.
We can also have a common policy file, or even a policy network
service for policy (just decorate it on top of a minimum set of
permissions required to get you started).</p>
<p>This is far less complicated than people are making out, it's not
atomic physics. Loom seems far more complicated than
SecurityManager. Policy features are added using policy
decorators. After you look through these implementations, you
will see it's not that complex.<br>
</p>
<p> Also I'm pretty sure a cluster of compute nodes with JVM's is
probably going to be called a server. Ron, your assumptions don't
apply to our use case, they apply to Sun File Policy provider.<br>
</p>
<p>When Ron writes that SecurityManager is disabled on the common
pool and Loom's virtual threads, I hope he means that these
threads have no privileges, rather than all privileges? There is
some documentation on the common pool regarding SecurityManger,
but little on Loom's virtual threads. Can someone point me to a
reference to security documentation on these features please?<br>
</p>
<p>
<blockquote type="cite">Security Manager is not a central
component for securing trusted server-side code, a good thing,
too, because few systems use it and it doesn’t defend against
some of the most common and dangerous exploits. In fact, the
Security Manager is already crippled <a
href="https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html">on
the common pool</a> (and on <a
href="https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html#startVirtualThread(java.lang.Runnable)">Loom’s
virtual threads</a>) because setting up appropriate security
contexts would defeat the performance requirements of those
constructs, and using it with <code class="language-plaintext
highlighter-rouge">CompletableFuture</code>s or any
asynchronous (or “reactive”) context requires the developer to
carefully <a
href="https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/security/AccessController.html">capture
and reestablish</a> security contexts as operations travel
from one thread to another.</blockquote>
</p>
<p>If we disable Java serialization, we don't use XML, we validate
invariants in our constructors and design for failure atomicity,
we design to encapsulate, we avoid shared mutable state as much as
possible, use immutability, we check third party libraries for
security vulnerabilities, we perform static code analysis and we
are running code using the principle of least privilege, we use
the latest available TLSv1.3 cyphers and disable earlier
versions. Do you believe we are still vulnerable to these most
common and dangerous exploits? <br>
</p>
<p>Perhaps we are still vulnerable to unknown or zero day exploits?<br>
</p>
<p>It is my opinion that removing the principle of least privilege
will not improve the security of our software, but rather degrade
it. But then Java hasn't had a good reputation for security in
recent years, thanks to Serialization, granted OpenJDK has done a
lot to swat bugs as they're discovered in recent years, it will
take a little more time to build a good reputation. Personally I
wouldn't be removing SecurityManager, I'd be addressing the issues
and cleaning it up so programs can be run with principles of least
privilege, I know it's not perfect, but nothing ever is, but it
should improve with time, if it's not neglected and replaced if
needed.<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Principle_of_least_privilege">https://en.wikipedia.org/wiki/Principle_of_least_privilege</a><br>
</p>
<p>Maybe Unix sockets will provide a performance boost, Sockets are
our major hotspot at 42.5%<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://pfirmstone.github.io/JGDMS/old-static-site/images/River-internet_mahalo_randomStressTest.PNG">https://pfirmstone.github.io/JGDMS/old-static-site/images/River-internet_mahalo_randomStressTest.PNG</a></p>
<p>I guess you now have a use case for what SecurityManager is
capable of.</p>
<p>It's a shame it took SecurityManager's proposed removal for you
to discover it has practical application. You are right on one
respect, not enough people take security seriously.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.</pre>
</body>
</html>