How to remove the SecurityManager

[Peter Firmstone]

Appended inline below.

On 29/07/2021 11:20 am, Peter Firmstone wrote:
>
> 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
>
7. https://www.oracle.com/java/technologies/javase/seccodeguide.html#8-5 
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.

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.

This method is papering over the underlying problem however, which is 
excessive privileges granted to code.

https://github.com/pfirmstone/JGDMS/blob/abb310f4ece90e31f2444e2368efe3864d3f9c09/JGDMS/jgdms-platform/src/main/java/net/jini/security/Security.java#L590

Anyone can find problems, it's the solutions to problems that matter.

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.

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.


> JEP 411 nukes backward compatibility so it cannot be fixed at all.
>
> Regards,
>
> Peter.
>