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