Low level hooks in JDK for permission checks.

Peter Firmstone peter.firmstone at zeus.net.au
Mon Jun 14 07:52:20 UTC 2021


Making things clearer if I can:

Some thoughts on hooks:

  * Utilize java.security.Provider, so as not to expose jdk
    implementation code.  Eg: a module declaration or
    META-INF/services/java.security.Provider to obtain relevant
    instances of java.security.Guard, where Permission implementation
    types are currently used.
  * Allow existing Permission classes to remain backward compatible,
    declare them as services, so that SecurityManager can be degraded as
    planned and Permission implementations can be gradually removed as
    planned. (Removes dependencies on Permission instance types).
  * Guard implementation's are typically required to have a constructor
    with two String arguments, (String name, String actions), can be
    passed as new String[]{ name, actions} constructor parameter to
    java.security.Provider.Service::newInstance.
  * Service must implement Guard interface, with Guard::check method
    (current Permission implementations implement this method and call
    System.getSecurityManager).
  * 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.
  * Using security provider avoids deadlock during Provider
    initialization, it must be listed as a provider in the java.security
    file or if security.overridePropertiesFile=true and
    -Djava.security.properties=file://path/additional.security defines
    providers, which would be useful for testing.

Break up guard service providers into current Permission types 
(independent instances to avoid circular deadlocks), developers only 
need implement those relevant to them and may only use checks for users 
if they wish:

"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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210614/80bad6dc/attachment.htm>


More information about the security-dev mailing list