Thanks Florian,
1. If I fix that bug, will JEP 411 be cancelled? BTW. Sparc isn't
vulnerable.
2. My primary use case is for SM is for authorization decisions for
remote users and services.
JSR-121: Java Application Isolation API Specification.
http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html
People keep confusing isolation with authorization, these aren't the
same thing, Isolates were designed for Isolation, which never made it
into Java SE and AccessController was designed for authorization access
controls. Other access controls are part of the language, such as
public, private, protected modifiers etc.
Applets had a weak form of isolation using ClassLoader's, and had
permissions to connect to their originating network address. I don't
think anyone has developed Applets for at least 10 years?
I'm talking about currently maintained software that uses SM for
authorization decisions and am looking for ways to re-implement
authorization in JDK libraries using Agents.
Often constructors contain permission guard checks, but due to finalizer
defenses, these cannot be instrumented without instrumenting private
static methods. The alternative is to instrument object methods
instead, however these would impact performance (although I'm
considering instrumenting ClassLoader object methods).
An example of a generated grant, note how the SHA-384 signature of the
file is captured, along with the User? This doesn't include dynamically
granted permissions which occur during authorization, then downloading,
class loading and unmarshalling of a service proxy.
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";
};
Without SM, everyone is authorized, our network connections will allow
everyone and anyone in, so I need to re-implement an authorization
layer, however OpenJDK has a monopoly on Java libraries.
An alternative that isn't being considered at this stage is to remove
support for TLS and Kerberos connections from the JDK, and use private
virtual networks and a VM instead, however that stops global service
discovery over IPv6, and constrains the software in many other areas as
well, so it's not being considered at this time.
Regards,
Peter.
On 2/08/2021 4:23 pm, Florian Weimer wrote:
* Peter Firmstone:
From our discussions, my interpretation is that OpenJDK is constrained
by corporate security policy; any issues with SecurityManager
infrastructure will be treated as confidential security issues and
have to be fixed with internal resources. Community volunteers won't
be allowed to handle them. Hence it's the maintenance burden. I see
this maintenance cost as a bureaucratic management issue, rather than
an issue with SM per se.
The dynamics would likely change if the community started fixing issues.
A starting point could be speculative execution vulnerabilities, which
are currently out of scope for the OpenJDK security process:
Java and Speculative Execution Vulnerabilities
<https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/000002.html>
I think any use of the security manager for isolation purposes would
have to address those issues.
Thanks,
Florian
