<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Some thoughts on hooks:</p>
<ul>
<li>Utilize the Service Provider API, so as not to expose jdk
implementation code. META-INF/services/java.security.Guard<br>
</li>
<li>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).<br>
</li>
<li>Guard implementation is required to have a constructor with
two String arguments, (String name, String actions).</li>
<li>Service must implement Guard interface.</li>
<li>Doesn't depend on Permission or any existing implementation
classes, completely customizable by the service implementation.</li>
<li>Application developers can also implement hooks using this
service.<br>
</li>
</ul>
<p>Break up guard service providers into current Permission types:</p>
"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"
<p>I would like to suggest adding a new provider type:</p>
<p>"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>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.</pre>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 13/06/2021 8:34 pm, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0b259e47-c6ec-54e8-e220-b5b5ea2ced8a@zeus.net.au">Thanks
Alan,
<br>
<br>
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.
<br>
<br>
An implementation can override Guard::check without requiring a
provider mechanism.
<br>
<br>
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.
<br>
<br>
Cheers,
<br>
<br>
Peter.
<br>
<br>
<br>
On 10/06/2021 11:55 pm, Alan Bateman wrote:
<br>
<blockquote type="cite">On 10/06/2021 07:40, Peter Firmstone
wrote:
<br>
<blockquote type="cite">
<br>
Just a quick question, would it be possible that some JFR
hooks might also be useable for an authorisation layer?
<br>
<br>
<br>
</blockquote>
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.
<br>
<br>
-Alan
<br>
</blockquote>
<br>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>