My thoughts on how to proceed with this is:
1. Develop authorization layer security provider services in OpenJDK,
back port it to Java 8 and Java 11 (these provide most of the
utilised functionality of SecurityManager, allowing developers to
only implement those which they need, without enabling
SecurityManager and editing policy files).
2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19.
3. Leave AccessController and AccessControlContext in place, provide a
security property that allows the stack walk to be disabled (One
ProtectionDomain to represent all code in JVM, without any
permissions, later making it the default, while allowing it to be
enabled) and continue to inject user Subject principles using
SubjectDomainCombiner for JAAS compatibility. Developers can
implement just the authorization they feel necessary for users and
develop their own configuration, or adapt existing.
4. At some point, preferably when StackWalker has equivalent
performance, replace the internals of AccessController.
Gut feel is that removal of AccessController, AccessControlContext and
DomainCombiner causes carnage with JAAS, it's a lot to deal with,
SecurityManager and Policy, I don't need them if I've got authorization
layer hooks in the JVM.
I wouldn't want to see SecurityManager and Policy be neutralized, it's
better to remove it and fail early so people update their software,
there's a risk they may update without realizing it's no longer fully
functional. Get rid of the baggage so people can start fresh with
better practices.
Note that I'll be implementing a full authorization layer based on least
privilege principles, that still utilizes a stack walk. I won't use the
standard Java Permission implementations, as I'd like to do things a
little differently, for usability reasons, this will do everything I
need at least. If the authorization layer is back ported, then I can
support all current versions. My policy files are generated, so I don't
need permission implementations to remain compatible.
Whatever happens with JAAS will need to be backported, so we can support
all versions.
Regards,
Peter.
On 14/06/2021 3:54 pm, Alan Bateman wrote:
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the first of several in a multi-release/multi-year effort.
It's way too early to give any guess as to when the APIs will be
removed. As the JEP says, future releases may degrade the SM APIs so
that System.getSM returns always returns null or
AccessController::doPriv just runs the action. This should mean that
libraries that are compiling to older releases should continue to
compile and run on those releases. When they run on some future
release that degrades the implementation then it will be as if there
is no SM. So I would say the impact is little to none for libraries
for the foreseeable future.
-Alan
On 13/06/2021 21:28, Rafael Winterhalter wrote:
I am currently looking into how I should address JEP 411 in my
library Byte
Buddy and I find it rather challenging. The problem I am facing is
that I
know of several users who rely on the security manager in their Java
8/11
applications. I would like to continue to support those users' use
cases as
long as I support Java versions that contain the security manager, which
will be for many years to come. At the same time, I would like to
address
the announced removal of the API and make sure that Byte Buddy can work
without it prior to the deadline when the library in its current state
would no longer link.
From my understanding of the intention of JEP 411, the API was
supposed to
be stubbed – similar to Android’s stubbing of the API - rather than
being
removed. However, with the announced deprecation for removal of
AccessController and SecurityManager, I understand that I would need to
fully remove the dispatching to work with future Java versions.
Furthermore, it is difficult to create a working facade for
dispatching to
the security manager only if it is available. Methods like
AccessController.doPrivileged are caller sensitive and by adding a
utility
to a library, this utility would leak to any potential user. It would
therefore require package-private dispatchers for any relevant package,
which would lead to a lot of copy-paste to retain backwards
compatibility
(given that a library cannot assume to be run as a module).
Finally, removing the API would mean that Byte Buddy versions of the
last
ten years would no longer link in future JDKs. For Byte Buddy where new
Java versions often require an update, that might not be a big issue but
many other libraries do support the API, I don’t feel it would be a
rather
severe restriction and cause unnecessary breakage if API is removed,
rather
than stubbed. I am thinking of libraries like Netty here which are
rather
omnipresent and would suddenly no longer link, a concept that is
unlikely
intuitive to a lot of developers.
Therefore, my question is: should SecurityManager, AccessController
and the
Policy APIs really be deprecated for removal? Rather, I think that
the APIs
should be deprecated, but be retained with stubbed implementations.
System.getSecurityMananger would then always return null.
System.setSecurityManager on the other hand could be deprecated for
removal. This way, existing code could continue to work as if the
security
manager is not active, which already is the common scenario and would
not
cause any disruption at the small price of keeping a handful of some
stubbed classes.
Thanks for advice on how this is intended to be handled by library
developers like me.
Best regards, Rafael
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
