[EXT] security-dev Digest, Vol 171, Issue 3

[Sean Mullan]

On 9/2/21 9:42 AM, Doyle, James wrote:
> Hi Sean,
> 
> Thanks for your response!
> 
> I re-checked the "Future Work" section of https://openjdk.java.net/jeps/411 and see the "Monitoring access to resources" use case / enhancement you were referring to.
> 
> The enhancement as worded focuses on monitoring the operations and seems ambiguous about whether blocking the operations is in scope ("while not necessarily restricting these operations").  Can I suggest updating the wording a little to be clearer that having the ability to block the operations is part of that use case?

Good point, although JFR is really a better solution for monitoring. In 
recent releases, we have added more security-specific events to JFR 
which help monitor TLS connections, certificates, deserialization, etc 
so we should continue to explore this area more to see if it can provide 
more security events, such as network/file access, etc.

So I would like to leave that one as-is. The "Blocking System::exit" 
bullet should be expanded to potentially include other operations such 
as file/network access.

> 
> Also, one of the things that's been helpful with Security Manager permission-based policies today, is the ability to base decisions about those operations on a whitelist of what's allowed for a given application, and that the resources in that whitelist can be fine-grained (specific DNS names, file paths, ports, etc).  Could that aspect be captured in the wording of that use case?  In other words, a feature for monitoring and blocking operations would be helpful if it could act not just as a blacklist of forbidden operations, but a whitelist of allowed operations and resources at a fine-grained level.

So one point that should be made clear is that we don't intend to 
replace the current Policy API and policy file implementation, etc. If 
we go down this route, it will be up to the application to decide if a 
particular operation should be blocked or not based on its own policies. 
The JDK will no longer be a Policy Decision Point.

--Sean

> 
> Thanks,
> Jim Doyle
> 
> -----Original Message-----
> 
> Date: Wed, 1 Sep 2021 15:03:22 -0400
> From: Sean Mullan <sean.mullan at oracle.com>
> To: security-dev at openjdk.java.net
> Subject: Re: JEP 411 - use cases
> Message-ID: <076900c6-5141-a3ca-6f3d-88416f84b83d at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi James,
> 
> On 9/1/21 11:48 AM, Doyle, James wrote:
>> Hi,
>>
>> Earlier this summer, our organization became aware of JEP-411 and the
>> plan to remove Security Manager in the future, and I?d like to add our
>> perspective to the use case / adoption aspect.
>>
>> We deploy and manage a number of server-side Java applications, both
>> developed in-house and from vendors, and currently use Java Security
>> Manager to provide an extra layer of security around the server
>> application code.? Enabling Security Manager in the server application
>> JVM provides an additional means to defend against malicious
>> users/clients exploiting vulnerabilities (in our application code or
>> third-party code) to access the host OS in ways the individual JVM and
>> application are not intended to act.? The fine-grained permission
>> model is very useful for giving the application code the least
>> privilege needed for its specific function.? 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.? Our organization operates under compliance oversight,
>> and the Security Manager policy for our applications provides one of
>> the controls we use to insure a secure environment.? We?re worried
>> about the impact to these controls should Security Manager be removed.
>>
>> Is the low adoption rate cited in the JEP (?After decades of
>> maintaining the Security Manager but seeing very little usage??)
>> anecdotal, or has it been measured somehow as part of proposing and implementing the JEP?
>> What qualifies as ?low? or ?little??
> 
> This is based on various pieces of data accumulated over the years such as incoming bug reports, surveys, external papers/studies of the SM, source code repositories, product searches, difficulties using the SM, declining usage on the client, etc.
> 
>> Is the use case above one that the OpenJDK team is considering, to
>> make sure workable alternatives are available before removing Security Manager?
> 
> As described in the Futures section of the JEP, we are looking at some alternatives for certain use cases. One of those is to potentially add a mechanism that allows applications to monitor and optionally block certain operations. The common use case listed in the JEP is blocking System.exit, but some others have requested being able to monitor and/or block file/network access. These and other alternatives need more discussion, but this is the list where it will be discussed.
> 
>> Some of our Security Manager usage is via Java EE / Jakarta EE
>> Security Manager permissions, and within that set, some apps
>> specifically use WildFly Security Manager.? Will the removal of
>> Security Manager from OpenJDK make related implementations like
>> WildFly Security Manager impossible to maintain as-is?? Will the
>> removal of Security Manager make users dependent on vendor-specific
>> implementations like WildFly Security Manager and unable to freely
>> move between Java EE / Jakarta EE implementations?
> 
> This is probably a question that is best answered by those that work on or support WildFly.
> 
> --Sean
> 
> 
> ------------------------------
>