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.
On 28/07/2021 9:12 am, Peter Firmstone wrote:
Our process for establishing whether third party libraries are trusted
before we use them:
1. Build dependency check using Owasp
https://owasp.org/www-project-dependency-check/ Reject any
dependencies that fail, see
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/pom.xml 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.
2. Static analysis using SpotBugs, then review identified bugs,
review source code if available. Reject if security bugs are
present, or fix / patch.
3. Profiling of permission access checks using:
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
4. Reviewing generated policy files, using grep, this example was
generated from over 2000 tests:
https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecuresharedvm.policy.new
5. 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.
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.
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.
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.
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.
If you removed applets, then there is no use case for a Sandbox, so why
remove SecurityManager?
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.
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.
grant codebase
"httpmd://${HOST}:9080/${mercury-dl.jar};sha-384=041531e5e3de288c121e865af8a46f7af86172ee0127dc4aff4f551c73a0ad604f51cb1c53076140fd415f957c14e8dd",
principal javax.security.auth.x500.X500Principal "CN=Outrigger"
{
permission org.apache.river.api.io.DeSerializationPermission
"MARSHALL";
permission net.jini.security.AuthenticationPermission
"javax.security.auth.x500.X500Principal \"CN=Outrigger\" peer
javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect";
};
Rather than throwing developers who use SM under the bus, we could be
given a migration path:
1. 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?
2. 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.
3. 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.
4. 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.
5. We still use AccessController and AccessControlContext to establish
TLS connections, why break it?
6. Get a tool to generate policy files (mine's only 653 lines of code).
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
JEP 411 nukes backward compatibility so it cannot be fixed at all.
Regards,
Peter.
