How to remove the SecurityManager

[Peter Firmstone]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210729/7329c8af/attachment.htm>