Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

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
>