We also use the SecurityManager for caller sensitive method calls.
I re-implemented a secure implementation of Java Serialization, using a
public API and fewer features (eg no circular links), in this
implementation, each class in an object's hierarchy has its own
namespace, the calling class is discovered using a SecurityManager
subclass.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
On 29/04/2021 3:37 pm, Peter Firmstone wrote:
Which version of Java is this planned for? Will the last version
supporting the security manager be a long term support version, eg
back ports of security patches and TLS technologies?
We have our own security manager implementation and policy provider
implementations. Both of these are high performance and non-blocking
and we are able to dynamically grant and revoke some permissions.
While I acknowledge the Java policy implementation has a significant
performance impact, due to blocking permission checks, ours is less
than 1%. Our software doesn't share PermissionCollection instances
among threads, or even have a Permissions cache,
PermissionCollection's are generated for each permission check and
discarded for garbage collection, the Permission object themselves are
cached (after initialization and safe publication), as are the results
of repeated permission checks. We also have our own Permission
implementations.
We have tools that generate policy files with least privilege,
although we will manually alter them with wildcards, for network
connections for instance.
In our software, dynamic permissions are granted after authentication
of TLS connections.
It is too early for me to tell if there are suitable replacement
technologies available. I can understand the motivation for reducing
Java's software development burden, but I think this version of Java
might be the last for us, it would certainly be good if a long term
support version was available, perhaps indefinitely lol.
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
On 16/04/2021 4:05 am, mark.reinh...@oracle.com wrote:
https://openjdk.java.net/jeps/411
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
