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,
