New candidate JEP: 411: Deprecate the Security Manager for Removal

[David Lloyd]

If it helps, we've solved this particular problem in a couple of places by
using an MR-JAR which selects an implementation using `StackWalker` when
Java 9+ is used.  I will say however that it appears to be slightly less
performant, which is unfortunate (but hopefully fixable at some point in
the future).

On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone <peter.firmstone at zeus.net.au>
wrote:

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

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210429/a587ef8c/attachment.htm>