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
