Re: [jakartaee-platform-dev] <permissions.xml> should we deprecate?

[Scott Stark <starksm64@xxxxxxxxx>]

The direction statement issue has only been created, but not fleshed out in any way:

https://github.com/eclipse-ee4j/jakartaee-platform/issues/406

I think the initial focus will simply be to try to ensure that current JVM level behaviors are not removed too quickly in order for Jakarta EE to be able to meaningfully introduce alternatives. Permission checks at ClassLoader, Thread, file/socket levels, etc. may not be easily replaced at the application server level. It is a general concern that teams supporting the JVM level issues don't see security manager related issues that derive from Jakarta EE usage, and so the platform team will have to provide feedback to the security-dev list to make use cases known.

On that topic, I thing one of the first things the platform team needs to do is to gather security manager use cases from vendor customers that illustrate where JVM level support is required, and where depreciation either needs to move more slowly, or be replaced by an alternative.

On Mar 4, 2022 at 9:53:09 AM, "Doyle, James, K" <jdoyle@xxxxxxxxxx> wrote:

Hi,

 

I was reading the thread in the subject line with interest.  Our company has JavaEE / JakartaEE applications using Java Security Manager (specifically the WildFly Security Manager in WildFly) and leverages permissions.xml to specify the permissions needed.  This has been useful to our teams in a couple ways:

 

·         Clarifies the special platform requirements of the application – network access and local file access – as an easily-located policy kept in one place that lives with the application itself.

·         Using a whitelist-based approach to this access means that unintended resource access during normal use is discovered and fixed during development.

·         The application has a layer of protection inside the JVM should a code vulnerability be exploited and an attempt made to access unauthorized resources.

 

Previously I posted similar concerns to the OpenJDK security mailing list, asking what we can expect from the JVM in the future to support our use case that Java Security Manager addressed.  (See https://mail.openjdk.java.net/pipermail/security-dev/2021-September/027279.html)

 

Given that permissions.xml was useful in the same way, I had a similar question about Jakarta EE: is there a feature on the roadmap to support the same use case in a different, non-Java-Security-Manager way?  It would still be a beneficial feature to be able to deploy applications to a Jakarta EE server along with a declarative description of what network and file resources they need to access, with the assumption that other access will be blocked.

 

Thanks,

Jim

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev