How to remove the SecurityManager

Peter Firmstone peter.firmstone at zeus.net.au
Tue Jul 27 23:12:32 UTC 2021


Thanks Remi,

Sand-boxing is a bad idea, we are in agreement, it's not something we 
do, personally I'm taking an interest in safer languages, eg Haskell on 
secure platforms, eg OpenBSD on Sparc64 *.

Perhaps JEP 411 is simply a reflection on the evolution of languages.  
Java was safer than C and C++ so replaced these, something safer again 
will replace Java.

I think people are getting our primary use case, authorization, confused 
with sandboxing (not on our use case list).  OpenJDK developers provided 
a Sandbox example, I just wanted to communicate that I didn't think it 
was a practical defense against exploits, nor applicable to our use case:

https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/

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.

One of my use cases for SM is for auditing to establish trust, and then 
using SM with POLP policy files generated following the audit, to turn 
off JVM features we're not using.   Our policy provider is performant 
and high scaling even with policy files containing 1000's of lines: 
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java

Our use of SM for access decisions occurs during and after 
authentication, but also defines access roles for trusted parties, it's 
not possible to replace SM authorization layer functionality (not to be 
confused with sandboxes).   Our use case is distributed systems, with 
trusted services and trusted clients, which have POJO proxy's, different 
service proxies are given different ProtectionDomain identity and these 
identities are used for authorization decisions.

In a simple Client - Server application, you only have one user, from 
the client and the thread runs with this permission, but our systems 
might be performing a transaction, with 5 different services, and the 
transaction service is the client of these 5 services, which are 
represented by their proxy ProtectionDomain's.   If one of the 
authenticated services is not authorized to participate in the 
transaction (eg a third party that's not on the contract, or maybe the 
contract expired), then it's not authorized and the transaction will 
fail.  This all occurs over secure authenticated connections, where both 
servers and clients are authenticated, who's the server and who's the 
client, well that gets a little blurred sometimes.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/transaction/Transaction.java

Back in the Jini days, Sun Microsystems, allowed different service 
proxy's to be loaded by the same ClassLoader, if they had the same 
CodeSource, they had the same identity if they had the same parent 
ClassLoader, we don't do that, ClassLoader's are assigned to a service 
proxy, based on it's authenticated identity.

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-pref-class-loader/src/main/java/net/jini/loader/pref/PreferredProxyCodebaseProvider.java

This system, at its foundations is based on Jini Extensible Remote 
Invocation (JERI), we've replaced the serialization layer, to use what 
we term atomic serialization and apply constraints during connection 
establishment over secure connections.

https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/core/constraint

We limit access based on both the service and user identity.  We 
generate our policy files by profiling (the tool creates a policy file 
with correct syntax, ready for immediate use), we recently added 
replacement of local file paths with properties for policy property 
expansion with cross platform trans-portability.  While its possible to 
use a dynamic proxy without downloading code, via an atomic 
serialization connection, it's not generally advised to do so with 
unauthenticated users, decisions around dynamic discovery, whether class 
loading or downloads are allowed, it's all based on policy decisions.

The problem with our software is its designed to operate on un-trusted 
networks, and SM infrastructure is involved in authorization decisions 
during the authentication process, as well as providing user credentials 
for secure connections.

We have no future Java migration path after JEP 411, the decision's been 
made, time to move on...

On the bright side, according the JEP 411, we did achieve what OpenJDK 
dev's thought to be almost impossible. :)   I'm pretty sure using the 
process I've documented above, you will identify 99% of accidental 
vulnerabilities in local code, and that was good enough for me lol.

> The threat of accidental vulnerabilities in local code is almost 
> impossible to address with the Security Manager.

* OpenBSD on Sparc (very well supported, Oracle should sell these lol, 
the only drawback is no zfs) is a good idea, no Spectre or Meltdown 
vulnerabilities.

buffy$ uname -a
OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64

Although this one's a couple of versions behind, time for an upgrade.

Regards,

Peter.

On 28/07/2021 5:52 am, forax at univ-mlv.fr wrote:
> ----- Original Message -----
>> From: "Alan Bateman" <Alan.Bateman at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>, "Peter Firmstone" <peter.firmstone at zeus.net.au>
>> Sent: Tuesday, July 27, 2021 6:33:25 PM
>> Subject: Re: How to remove the SecurityManager
>> On 27/07/2021 17:11, Remi Forax wrote:
>>> Peter, this is how you remove the security manager using the jdk 17 (the
>>> SystemMirror class is specific to a JDK version).
>>>
>>> Any in-process security measures fail if the API let you to peek and poke the
>>> memory like Unsafe does.
>> I hope you aren't really suggesting anyone does this :-)
> nope, it's a small example to explain why in-process sandboxing is a bad idea.
>
>
>> It's dependent
>> on the field layout so can break and crash the VM if it doesn't match.
>> Also it assumes that someone gets theUnsafe before a SM is set.
> yes, it's just an example, you have infinite variations using JNI/JNA/JNR or panama and changing some field value.
>
>> -Alan
> Rémi



More information about the jdk-dev mailing list