Low level hooks in JDK for instrumentation of permission checks.

[Peter Firmstone]

Clarification, utilize java.security.Provider.

So this might use a module declaration or 
META-INF/services/java.security.Provider, sorry got muddled with typical 
ServiceLoader usage below.

The reason for choosing Provider is that it allows constructor 
parameters, it's also security related and can require code signing, not 
sure if that should be a requirement.

Another reason for using security provider is to avoid 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.

Dynamic loading a provider using Security.addProvider or 
insertProviderAt causes security checks, each Guard::check call would 
try to initiate "SECURITY" Provider loading causing deadlock.  To avoid 
deadlock at the very least the "SECURITY" and "PROPERTY" 
java.security.Guard services would need to be loaded by java.security at 
startup.

grant codebase "jrt:/java.xml.crypto"
{
     permission java.util.PropertyPermission 
"java.specification.version", "read";
     permission java.security.SecurityPermission 
"putProviderProperty.XMLDSig";
};

Need to be careful with loading and recursive permission checks, it's ok 
if a permission check fires off permission checks that cause loading of 
other providers, we just can't ask the provider that is being 
dynamically loaded to perform permission checks on itself, or any 
circular relationship between providers.

Basically it's good to have separate providers for each permission type 
as it helps avoid deadlocks.

grant codebase "jrt:/jdk.crypto.cryptoki"
{
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
};

On 14/06/2021 9:56 am, Peter Firmstone wrote:
> 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
0498 286 363
Zeus Project Services Pty Ltd.