JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210802/f2accbe0/attachment.htm>