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

Peter Firmstone peter.firmstone at
Sat May 1 02:04:00 UTC 2021

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 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.

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.


> 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 408 
> <>, 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.

Peter Firmstone
Zeus Project Services Pty Ltd.

On 16/04/2021 4:05 am, mark.reinhold at wrote:
>    Summary: Deprecate the Security Manager for removal in a future
>    release. The Security Manager dates from Java 1.0. It has not been the
>    primary means of securing client-side Java code for many years, and it
>    has rarely been used to secure server-side code. To move Java forward,
>    we intend to deprecate the Security Manager for removal in concert with
>    the legacy Applet API (JEP 398).
> - Mark

More information about the jdk-dev mailing list