JEP 411, removal of finalizers, a path forward.
peter.firmstone at zeus.net.au
Mon Aug 2 07:49:33 UTC 2021
1. If I fix that bug, will JEP 411 be cancelled? BTW. Sparc isn't
2. My primary use case is for SM is for authorization decisions for
remote users and services.
JSR-121: Java Application Isolation API Specification.
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.
principal javax.security.auth.x500.X500Principal "CN=Outrigger"
"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.
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
> I think any use of the security manager for isolation purposes would
> have to address those issues.
More information about the jdk-dev