<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java</a></li>
</ol>
<p>JEP 411 nukes backward compatibility so it cannot be fixed at
all.</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
</body>
</html>