Re: JEP 411: Deprecation with removal would break most existing Java libraries
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
Re: Low level hooks in JDK for instrumentation of permission checks.
Some thoughts on hooks: * Utilize the Service Provider API, so as not to expose jdk implementation code. META-INF/services/java.security.Guard * Allow existing Permission classes to remain backward compatible, declare them as services, so that SecurityManager can be degraded as planned and these services are gradually removed. (Removes dependencies on Permission instance types). * Guard implementation is required to have a constructor with two String arguments, (String name, String actions). * Service must implement Guard interface. * Doesn't depend on Permission or any existing implementation classes, completely customizable by the service implementation. * Application developers can also implement hooks using this service. Break up guard service providers into current Permission types: "AWT" "FILE" "SERIALIZABLE" "MANAGEMENT" "REFLECT" "RUNTIME" "NET" "SOCKET" "URL" "FILE-LINK" "SECURITY" "SQL" "LOGGING" "PROPERTY" "MBEAN" "MBEAN-SERVER" "MBEAN-TRUST" "SUBJECT-DELEGATION" "TLS" "AUTH" "KERBEROS-DELEGATION" "KERBEROS-SERVICE" "PRIVATE-CREDENTIAL" "AUDIO" "JAXB" "WEB-SERVICE" I would like to suggest adding a new provider type: "PARSE-DATA" - To be called by any code about to parse data, eg deserialization, XML, JSON, SQL, etc. Granted to users, so that it can only be performed after authentication. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 13/06/2021 8:34 pm, Peter Firmstone wrote: Thanks Alan, I've been thinking that it may be preferable to have hooks that allowed us to inject our own permission checks, rather than retaining existing permission checks. An implementation can override Guard::check without requiring a provider mechanism. The other advantage is the ability to customize Permission implementations, such as allowing address ranges in a SocketPermission implementation and not consulting DNS to resolve host names. Cheers, Peter. On 10/06/2021 11:55 pm, Alan Bateman wrote: On 10/06/2021 07:40, Peter Firmstone wrote: Just a quick question, would it be possible that some JFR hooks might also be useable for an authorisation layer? JFR events can't be used to intercept/veto operations, assuming that is what you are asking. However, it might be that JFR events are monitored as part of some overall security approach that takes into account events recorded for health, performance, or troubleshooting purposes. -Alan
Re: Low level hooks in JDK for instrumentation of permission checks.
Thanks Alan, I've been thinking that it may be preferable to have hooks that allowed us to inject our own permission checks, rather than retaining existing permission checks. An implementation can override Guard::check without requiring a provider mechanism. The other advantage is the ability to customize Permission implementations, such as allowing address ranges in a SocketPermission implementation and not consulting DNS to resolve host names. Cheers, Peter. On 10/06/2021 11:55 pm, Alan Bateman wrote: On 10/06/2021 07:40, Peter Firmstone wrote: Just a quick question, would it be possible that some JFR hooks might also be useable for an authorisation layer? JFR events can't be used to intercept/veto operations, assuming that is what you are asking. However, it might be that JFR events are monitored as part of some overall security approach that takes into account events recorded for health, performance, or troubleshooting purposes. -Alan -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd.
