JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

I also think good developers will add these security features.

The problem is that Permissions are currently used to regulate access 
control because this is how we've been told it should be done for over 
20 years.

Now maybe people aren't using the Java FilePolicy provider (for reasons 
stated previously), but as has been discovered, they often will override 
SecurityManager and implement some form of access control on trusted 3rd 
party code.

Trusted code - Developed by people with good intentions - includes third 
party library code, we check it for known vulnerabilities at build time 
using OWASP, but we don't audit it ourselves as this requires 
understanding how the internals work and we are using it like a black 
box.  If we have concerns we might perform static analysis, but we don't 
do that for dynamic code, eg maven dependencies and then we are 
powerless to do anything about it, other than report the bug, so access 
control can be used to mitigate until it's fixed, or we can use the 
principle of least privilege so we are not impacted by it.

Java Serialization is also a form of parsing information, just like PDF 
documents and other file formats, problems with the Sandbox; there was 
no Permission to limit which classes could be deserialized, and JVM code 
always has AllPermission, so we couldn't restrict it either.  
Additionally there was no ProtectionDomain to represent the data being 
deserialized, and whether it was trusted or untrusted, these security 
features wouldn't have been difficult to add, however we rely on the 
platform developers to see the benefits.  We are all only human.

In JGDMS there are constraints we apply to services which require 
authentication and encryption, which must be met before deserialization 
or any downloads can proceed.

In our re-implementation of Atomic Java Serialization, we use a 
DeserizablePermission, to limit which libraries can perform 
de-serialization.   This is in addition to the use of failure atomic 
constructors, so we don't break object encapsulation.

We also perform static analysis at build time and fix these bugs too.

SecurityManager has much influence in access decisions in our software, 
we won't have the resources to upgrade, there's a massive amount of 
security auditing required before we could even consider it.   Our only 
option is to participate in the maintenance of existing Java versions.   
Java will be our COBOL. We will be capable of using Java 1.8 to 1.17, 
but not Java 2.0 (after disablement occurs).

Obviously removing SecurityManager infrastructure from OpenJDK is a 
significant undertaking requiring significant resources to audit the 
impacts of removal of Permission checks, unfortunately we don't have 
these resources and the alternative methods of putting alternative 
access controls in place isn't obvious and will require research, as you 
state below, I know very little about how this can be done without using 
existing Java access controls.

I think during this transition period, while developers are 
reestablishing what constitutes secure programming, there will be many 
new bugs exposed that SecurityManager was obscuring.

Personally, I will be observing from the sidelines to learn new security 
features and best practices I'm not yet aware of.  It's always best to 
wait and see the outcome of experiments before diving in.

The problem with Security is many developers don't like it, or want it 
to be someone else's problem, so we will always have reasons to remove 
whatever Security API's are added to Java because of limited use.

Perhaps I'm conflating security with access control again?

-- 
Regards,
  
Peter

On 14/05/2021 2:15 am, Sean Mullan wrote:
>
>
> On 5/12/21 5:41 PM, Peter Tribble wrote:
>> Let me give a concrete example:
>>
>> Parsing and rendering a PDF file that may contain references to fonts 
>> or other resources.
>> We know exactly where the files are installed, so wish to allow the 
>> rendering routine access
>> to the fonts it will need. But not to any other files, and not 
>> (normally) to network resources at
>> all. Note that we trust the code, but not necessarily the document 
>> it's parsing. (Although the
>> document itself may be perfectly well formed - document formats often 
>> allow embedding
>> references to 3rd-party objects, undesirable as that may be.)
>>
>> There are a range of such issues in document parsing and rendering. 
>> And unfortunately, the
>> good libraries for this task are proprietary so we can't modify them 
>> to apply the restrictions
>> we're after. The (server-side) application does need access to files 
>> and network resources at
>> other times; it's only when it goes into the rendering step that we 
>> lock it down, and unlock it
>> once done.
>
> I know very little about this area, but I would think a good PDF 
> rendering library would include security features which prevent 
> arbitrary file/network access from untrusted documents by default or 
> at least give you the ability to control that.
>
> --Sean