<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>