Re: [jakartaee-platform-dev] [EXT] Re: <permissions.xml> should we depre

["Doyle, James, K" <jdoyle@xxxxxxxxxx>]

Thanks, Arjan.

 

I agree that architecting the application carefully and applying lower-level protections can mitigate the overall concerns.  But I still had a couple thoughts in response:

 

·         Java/Jakarta EE has been a useful way to field applications in many different environments and circumstances, including legacy apps that have special requirements, where a “minimal OS” and a minimally-privileged OS user that are dedicated strictly to the Java EE app server aren’t necessarily feasible.  For instance, a VM that needs to run both Java EE apps and SMB.  Having Security Manager / permissions.xml as a layer of security within the JVM itself has been a useful way to insure that the application requests are confined to what the app server is meant to do.

·         Even with just the app server, there may be circumstances where it’s difficult to whittle the OS privileges down as far as you would like, depending on the product.  E.g., the JBoss EAP product, at least in the distribution we used, was typically set up to be all one OS user, including file ownership of the software, configuration, and runtime data files, and process ownership of the JVM process.  It’s useful to have Security Manager / permissions.xml there to specify what the running application should really be able to do, as a subset of all the things that OS user can modify.

·         Going along with the legacy environments theme above, an organization may definitely have firewall tools at their disposal, but it’s not necessarily true that the management and workflow that governs the firewall, is set up for developers to easily interact with.  Being able to specify a kind of network policy within Security Manager / permissions.xml in a declarative way is useful for development teams rolling out those changes quickly and accurately, without necessarily relying on a lengthy firewall configuration update workflow.  Ideally developers can ultimately interact with software-defined networking like in the container/cloud world, but lots of teams may be running JVMs and app servers in environments that aren’t there yet.

 

Thanks,

Jim

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of arjan tijms
Sent: Friday, March 4, 2022 5:46 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [EXT] Re: [jakartaee-platform-dev] <permissions.xml> should we deprecate?

 

*** EXTERNAL email. Please be cautious and evaluate before you click on links, open attachments, or provide credentials. ***

 

 

On Fri, Mar 4, 2022 at 4:53 PM Doyle, James, K <jdoyle@xxxxxxxxxx> wrote:

Hi,

 

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)

 

> The permissions give us a way to use a deny-by-default model and require a whitelist of the files, directories, hosts, ports, URLs, etc. that each application actually needs.

Perhaps this needs to be looked at, and investigated why exactly a minimal OS in a virtual server, running the AS with a user with minimal privileges, and a restricted number of outgoing ports and hosts (outgoing firewall) can not do this.

The concerns themselves as reported seem absolutely valid, there's no question about that. But just anecdotal in my own experience for my own use cases I've always been able to mitigate those concerns using the above strategy.

 

Kind regards,

Arjan