Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization?

[Sean Mullan]

-bcc jdk-dev
-cc security-dev

On 4/30/21 10:04 PM, Peter Firmstone wrote:
> Having had a day to think about this JEP, I have a simple request, I'd 
> like to add to this JEP.
> 
> Because those of us who require Access Control functionality will have 
> to remain with a legacy version of Java until EOL and following that 
> need to maintain and backport security patches ourselves.
> 
> Create a new JEP for deprecation and removal of Java's Serialization 
> implementation.  Please remove Java Serialization first, then remove the 
> Security Manager a version after that (Deprecating both now).  Make Java 
> more secure first, before reducing security.  We know that Serialization 
> will eventually be removed, and removing it will allow the community to 
> maintain a community LTS version with fewer resources.  After removal, 
> leave the public Serialization API in place, abstract without an 
> implementation, to allow third party implementations to continue utilize 
> and implement it and existing code to compile also add SerializerFactory 
> to RMI.
> 
> We've had much longer (at least 10 years notice) to understand why Java 
> Serialization should be avoided and the luxury of many viable migration 
> alternatives to implement, not to mention it's the king of maintenance 
> burdens and security vulnerabilities.
> 
> Don't get me wrong, removing Serialization will cause pain, but it's not 
> chronic pain, because we can migrate to alternatives, we will still be 
> able to migrate to later versions of Java, at least until the removal of 
> Access Control.
> 
> Clearly there is no way for a library to provide AccessController 
> functionality, it's only possible to provide this functionality at the 
> platform level, not so with Serialization.
> 
> We develop software that works peer to peer / distributed that blurs the 
> lines between server and client.  We realize this is no longer a target 
> market for Java development, along with applets and client code.
> 
> Fine grained access control is required to control access to sensitive 
> data, to prevent unauthorised access.
> 
> Now IoT, is often called the "Internet of S___t" because it lacks security.
> 
> We realise there are shortcomings with Java Security, it's not perfect 
> but it does work for access control, when only limited access is 
> permitted, I am wondering how to maintain equivalent security without an 
> AccessController?  What other languages or platforms do security well, 
> that could be used to provide guidance?
> 
> We put into practice the principle of least privilege, we have the 
> ability to dynamically grant additional permission as needed, we also 
> restrict the permissions that can be granted.   Java 1.4 was modified to 
> allow dynamically granted permission, even though it wasn't implemented 
> by the Java Policy provider, it was intended to be extensible for 
> developers to develop their own implementations, and we did.
> 
> This is functionality that is currently working, it remains in use and 
> under development it is not legacy code.   It is the result of a 
> significant investment of time and money and we lack the resources to 
> rewrite it in another language that supports fine grained access control.
> 
> We use dynamic code, via Maven :)
> 
> In our software we use a ProtectionDomain to represent a remote server, 
> because a thread only runs with the user's Subject (and that Subject 
> must be carefully preserved for other threads), there is no way to 
> represent the remote Server's Subject in a local domain , other than 
> with a ProtectionDomain.   Our software is peer to peer, clients can be 
> servers and servers can also be clients.  Code to interact with the 
> server is downloaded via Maven and loaded.  Any permission's granted to 
> a user, are injected into the stack when run as the client Subject, to 
> authenticate the user for the server and establish a secure connection, 
> calls made by the client are run with the user's Subject on the server, 
> again for access control purposes.  This functionality is beyond the 
> capability of Java RMI, we aren't using Java RMI to do this.  This is 
> very important to allow us to make fine grained access control 
> decisions, or perform event notification callbacks over secure 
> connections, without this feature, we can't make a secure connection 
> with a callback, and you know what happens when you have to do 
> something, but cannot do it securely?   We only grant network access 
> directly back to the server, downloaded code has been verified and is 
> not expected to cause denial of service, by consuming resources etc, but 
> we don't want to grant third party access to files, or random network 
> connections, we still have privacy obligations for third party information.
> 
> We can allow a third party to use unsigned certificates to sign their 
> jar files or use a checksum and we verify them using a secure connection 
> to the server, prior to loading.   We then dynamically grant permissions 
> to the server's self signed Certificate (used to sign the jar file), or 
> a ProtectionDomain, after authenticating the server and receiving a 
> check sum or certificate from it.  So the client authenticates the 
> server using signed TLS certificates (EG by letsencrypt.org or a trusted 
> CA). We use self signed certificates on Jar files if we sign them, we 
> are actually trusting the server entity in this case, eg a trusted 
> company, but also placing restrictions on them.

I am probably missing something, but I don't understand how this is 
secure if you are using TLS server certificates as the basis for 
authenticating signed code. These are two very different use cases.

> If we remove access control, third parties will be able to open local 
> network connections and freely and use Java Serialization over unsecured 
> connections, exposing us to an attacker who can use a gadget attack. 
> Presently they cannot open a network connection, access files or do much 
> of anything without Permission.  All those protections will be removed 
> with this JEP.
> 
> from https://community.letsencrypt.org/t/do-you-support-code-signing/370
> 
>> Code-signing certificates as they’re used today are part of systems 
>> that try to decide whether a software source is malicious or 
>> legitimate. I don’t think Let’s Encrypt could easily play that kind of 
>> role when issuing certificates free of charge with an automated 
>> process without checking the real-world identity of the applicant. We 
>> could confirm that a code signing certificate applicant controls a 
>> domain name like iurewnrjewknkjqoiw.biz 408 
>> <http://iurewnrjewknkjqoiw.biz>, but that doesn’t give users or 
>> operating system developers much ability to know whether software that 
>> that applicant publishes is trustworthy or malicious.
> 
> The JVM is one of very few platforms that has sufficient capability to 
> allow us to do this.
> 
> If I could chose my pain, I would chose to remove Java Serialization 
> first, before SecurityManager because while I understand the maintenance 
> burden needs to be reduced for the ongoing viability of the Java 
> platform, security is still of utmost importance, as the vulnerabilities 
> of Java Serialization killed of client development.

I don't think it is appropriate to block deprecation of the Security 
Manager until serialization is removed. Note that we have added 
mechanisms such as Serialization Filters [1] to help applications secure 
their serialization dependencies and that do not require a Security 
Manager to be enabled. We also are continuing to look at other 
improvements in this area, as well as introducing new features such as 
Records that can be serialized more securely [2].

--Sean

[1] 
https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A
[2] https://inside.java/2021/04/06/record-serialization-in-practise/