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, fo...@univ-mlv.fr wrote:
----- Original Message -----
From: "Alan Bateman" <alan.bate...@oracle.com>
To: "Remi Forax" <fo...@univ-mlv.fr>, "Peter Firmstone"
<peter.firmst...@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
