<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Forgot to cc.<br>
    </p>
    <div class="moz-forward-container">-------- Forwarded Message
      --------
      <table class="moz-email-headers-table" cellspacing="0"
        cellpadding="0" border="0">
        <tbody>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
            </th>
            <td>Re: Low level hooks in JDK for instrumentation of
              permission checks.</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
            <td>Mon, 14 Jun 2021 15:13:15 +1000</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
            <td>Peter Firmstone <a class="moz-txt-link-rfc2396E" href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a></td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:jdk-dev@openjdk.java.net">jdk-dev@openjdk.java.net</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      Clarification, utilize java.security.Provider.<br>
      <br>
      So this might use a module declaration or
      META-INF/services/java.security.Provider, sorry got muddled with
      typical ServiceLoader usage below.<br>
      <br>
      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.<br>
      <br>
      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=<a class="moz-txt-link-freetext" href="file://path/additional.security">file://path/additional.security</a>
      defines providers, which would be useful for testing.<br>
      <br>
      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.<br>
      <br>
      grant codebase "jrt:/java.xml.crypto"<br>
      {<br>
          permission java.util.PropertyPermission
      "java.specification.version", "read";<br>
          permission java.security.SecurityPermission
      "putProviderProperty.XMLDSig";<br>
      };<br>
      <br>
      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.<br>
      <br>
      Basically it's good to have separate providers for each permission
      type as it helps avoid deadlocks.<br>
      <br>
      grant codebase "jrt:/jdk.crypto.cryptoki"<br>
      {<br>
          permission java.lang.RuntimePermission
      "accessClassInPackage.sun.security.util";<br>
      };<br>
      <br>
      On 14/06/2021 9:56 am, Peter Firmstone wrote:<br>
      <blockquote type="cite">Some thoughts on hooks:<br>
        <br>
         * Utilize the Service Provider API, so as not to expose jdk<br>
           implementation code.  META-INF/services/java.security.Guard<br>
         * Allow existing Permission classes to remain backward
        compatible,<br>
           declare them as services, so that SecurityManager can be
        degraded as<br>
           planned and these services are gradually removed. (Removes<br>
           dependencies on Permission instance types).<br>
         * Guard implementation is required to have a constructor with
        two<br>
           String arguments, (String name, String actions).<br>
         * Service must implement Guard interface.<br>
         * Doesn't depend on Permission or any existing implementation
        classes,<br>
           completely customizable by the service implementation.<br>
         * Application developers can also implement hooks using this
        service.<br>
        <br>
        Break up guard service providers into current Permission types:<br>
        <br>
        "AWT"<br>
        "FILE"<br>
        "SERIALIZABLE"<br>
        "MANAGEMENT"<br>
        "REFLECT"<br>
        "RUNTIME"<br>
        "NET"<br>
        "SOCKET"<br>
        "URL"<br>
        "FILE-LINK"<br>
        "SECURITY"<br>
        "SQL"<br>
        "LOGGING"<br>
        "PROPERTY"<br>
        "MBEAN"<br>
        "MBEAN-SERVER"<br>
        "MBEAN-TRUST"<br>
        "SUBJECT-DELEGATION"<br>
        "TLS"<br>
        "AUTH"<br>
        "KERBEROS-DELEGATION"<br>
        "KERBEROS-SERVICE"<br>
        "PRIVATE-CREDENTIAL"<br>
        "AUDIO"<br>
        "JAXB"<br>
        "WEB-SERVICE"<br>
        <br>
        I would like to suggest adding a new provider type:<br>
        <br>
        "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.<br>
        <br>
      </blockquote>
      <pre class="moz-signature">-- 
Regards,
 Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.

</pre>
    </div>
  </body>
</html>