<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Appended inline below.<br>
</p>
<div class="moz-cite-prefix">On 29/07/2021 11:20 am, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7164cfa7-d76a-5de0-dcee-1eda919bcfc4@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>The intent of the following process is to perform a targeted
audit, which allows inspection of small parts of the code
identified by these steps.</p>
<div class="moz-cite-prefix">On 28/07/2021 9:12 am, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ff333e4e-d5ee-8a31-a473-48834bada5b1@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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/"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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.</li>
</ol>
</blockquote>
<p>In the construction industry, a similar approach is used by
structural engineers and weld inspectors, when inspecting welds
for defects, using Ultrasonic, X-Ray or visual inspection, weld
defects in structures have the potential to cause catastrophic
failure and multiple fatalities, likely worse consequences than
a bug in Java, so engineers identify critical areas for
inspectors to target with 100% coverage, perhaps by UT or X-Ray,
to inspect the weld internally, then the structural engineer
will nominate to inspect 10% of other areas with UT, with 100%
visual inspection, for example, if defects are found, then they
will increase UT inspection coverage, welds need to be gouged
out and re-welded, until the inspector is satisfied with
quality.</p>
<p>A targeted code audit process will also identify code quality,
if there are many bugs, don't use it, even if these aren't
security bugs.<br>
</p>
<p>This can hardly be compared with the approach used for running
Applets in a sandbox that may have malicious intent, in that
case no auditing has been performed at all.<br>
</p>
<p>This use case of SecurityManager recognizes shortcomings of
Java platform security. Sandboxing was a marketing term used
for Applets, I don't know the origin of the term sandbox when
used for computer security, but whenever there is a sandbox,
there is a risk of escape, and simplicity is thy friend, it
should be left to cyber security professionals.<br>
</p>
<p>If you removed applets, then there is no use case for a
Sandbox, so why remove SecurityManager? <br>
</p>
<p>Come on honestly, JEP 411 is confirmation biased, is overly
focused on sandboxing and therefore not factual or relevant,
I've provided sufficient evidence contrary to it's claims. It
needs to take the ability to migrate code into account as well
as use cases other than sandboxing.<br>
</p>
<p>We use SM to prevent loading of untrusted (unaudited) code and
untrusted (unauthenticated) data, but we don't use it as a
sandbox to attempt to encapsulate malicious code and malicious
users, we use it for authorization decisions, for external users
and services, this could also be applied to Web Services, not
just Jini services, these authorization decisions prevent
loading untrusted code and parsing untrusted data.</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>
};<br>
</p>
<p>Rather than throwing developers who use SM under the bus, we
could be given a migration path:</p>
<ol>
<li>Review and reduce the number of permissions focused *only*
on authorization use cases. Eg: Give Properties useful for
authorization their own guarded area in the Property map? I
mean, why are we guarding java.util.PropertyPermission
"java.specification.version", "read" and many others like
it? Fix SocketPermission, add netmask wild cards, use
RFC3986 normalization, stop using DNS. Ever heard of DNS
spoofing?<br>
</li>
<li>What about parsing of data? Such as XML and Java
Serialization, among others, this should have a permission
check, that when granted to users, ensures the data source has
been authenticated. This is a server application, not
client. Permission to parse data should only be granted to
user principal's. No user, then the data is untrusted and
shouldn't be parsed.<br>
</li>
<li>Create a guard security provider interface to replace
permission checks, to allow developers to focus on their
authorization needs, that would allow us to completely ignore
permission checks that are irrelevant and replace bad
implementations like SocketPermission.<br>
</li>
<li>Consider simplification of "Voodoo", maybe instead of trying
to check every Thread stack (inheriting call stacks), if there
is no doPrivileged call on the current Thread's stack (reduces
shared state, it's thread confined), then report it and throw
a SecurityException, don't try to inherit thread context,
because it doesn't work for executor tasks. Then it will be
fixed downstream instead of allowed to create viral permission
checks that violate the principle of least privilege. This
is not a security vulnerability risk, we are only using it for
authorization, not sandboxing and it will make policy files
much shorter, improving readability.<br>
</li>
<li>We still use AccessController and AccessControlContext to
establish TLS connections, why break it?</li>
<li>Get a tool to generate policy files (mine's only 653 lines
of code).
<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"
moz-do-not-send="true">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java</a></li>
</ol>
</blockquote>
<p>7.
<a class="moz-txt-link-freetext" href="https://www.oracle.com/java/technologies/javase/seccodeguide.html#8-5">https://www.oracle.com/java/technologies/javase/seccodeguide.html#8-5</a>
Class::getProtectionDomain shouldn't return a null
ProtectionDomain for Java platform library code (the java library
is over-privileged), instead use modules: jrt://java.base, etc, so
we can grant permissions to authenticated users instead of code,
and in this case to ensure that there is an authenticated user on
the stack. The user is the data source during de-serialization. <br>
</p>
<p>I added Security::doAs methods that appended a Subject
ProtectionDomain, rather than injecting Principal's into every
ProtectionDomain on the stack, this does two things, one allows a
Subject to be more privileged than some code, that it interacts
with and also to reduce the intersection of permissions, in the
presence of privileged domains (like the Java platform libraries
above), to avoid the security issues described. <br>
</p>
<p>This method is papering over the underlying problem however,
which is excessive privileges granted to code.<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS/blob/abb310f4ece90e31f2444e2368efe3864d3f9c09/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590">https://github.com/pfirmstone/JGDMS/blob/abb310f4ece90e31f2444e2368efe3864d3f9c09/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590</a><br>
</p>
<p>Anyone can find problems, it's the solutions to problems that
matter.</p>
<p>99% of problems with SM have been solved outside of OpenJDK. I
can't see maintenance being a major issue if OpenJDK stops
treating it like a sandbox, and instead, starts treating it like
an authorization layer and reduce its complexity and mostly
automate it. It doesn't require as much work as you suspect.<br>
</p>
<p>JGDMS tests are run with security enabled by default, that
includes generating TLS certificates, signing them with a test CA,
then adding them to trust stores and key stores. It's been over
10 years since I've run tests without SM enabled, I'm not even
sure it works without it.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:7164cfa7-d76a-5de0-dcee-1eda919bcfc4@zeus.net.au">
<ol>
</ol>
<p>JEP 411 nukes backward compatibility so it cannot be fixed at
all.</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>