<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Having implemented SecurityManager and Policy providers, I'd like
to comment on some of the assessments, some thoughts:</p>
<ul>
<li>Poor performance, this is specific to the Java Policy
implementation, I have addressed this in my implementations,
performance impact is imperceptible, I know how to address it.<br>
</li>
<li>Brittle permission model - Agreed, it is brittle. <br>
</li>
<ul>
<li>Developers should use doPrivileged blocks to make security
sensitive calls, so only one domain is on the call stack.
Agreed when they don't do this it causes viral permission
expansion.<br>
</li>
<li>Implementing Deny would address the example given.</li>
<li>Un-trusted code should never be run on the JVM, however some
code is more trusted, or well audited, so we may wish to limit
code that doesn't require privileges, based on principle of
least privilege.</li>
<li>Is there a way to simplify Permission's? We can write tools
to generate policy files (I have).</li>
</ul>
<li>Difficult programming model</li>
<ul>
<li>If the library developer uses doPrivileged blocks and
documents the permissions, then the application code doesn't
require those permissions, as it is not on the call stack.</li>
<li>Agreed that most developers don't do this.</li>
<li>I use a tool to generate policy files that capture the viral
growth of permissions, these still require some editing, eg to
add system properties.<br>
</li>
</ul>
</ul>
<p>Is there a simpler way to limit permissions of library code?<br>
</p>
<p>I have gotten so used to secure coding, because we use it, I
don't find it difficult, writing non blocking or good concurrent
code is more difficult and developers make lots of mistakes with
race conditions, visibility and synchronization.</p>
<p>There are good static code analysis tools that identify poor
coding practices, the same tools could be updated to include
secure coding practices as well, to address viral permission
expansion.</p>
<p>Perhaps if we instead address the performance and usability
issues, we could improve adoption,so it adds to Java's appeal,
rather than detracting from it?</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
<p>Comments and code from one of my policy implementations (I have a
few policy implementations that use the decorator pattern to add
functionality, like dynamic permission grants):<br>
</p>
<p>* If there is sufficient interest, we can implement a DENY
clause, <br>
* in this case DENY cannot apply to GRANT clauses that contain<br>
* {@link java.security.AllPermission}, the domains to which a
DENY clause<br>
* would apply will be a less privileged domain. For example a
user could be<br>
* granted SocketPermission("*", "connect"), while a DENY clause
might<br>
* list specific SocketPermission domains that are disallowed,
where a DENY <br>
* clause has precedence over all GRANT clause Permissions except
for AllPermission.<br>
</p>
<p><br>
</p>
<p>@Override<br>
public boolean implies(ProtectionDomain domain, Permission
permission) {<br>
if (permission == null) throw new
NullPointerException("permission not allowed to be null");<br>
if (domain == myDomain) {<br>
PermissionCollection pc = myPermissions;<br>
return pc.implies(permission);<br>
}<br>
Class klass = permission.getClass();<br>
// Need to have a list of Permission's we can sort if
permission is SocketPermission.<br>
NavigableSet<Permission> perms = new
TreeSet<Permission>(comparator);<br>
PermissionGrant [] grantRefCopy = grantArray;<br>
int l = grantRefCopy.length;<br>
/* Check for privileged grants first to avoid recursion
when <br>
* privileged domains become involved in policy decisions
*/<br>
for (int j = 0; j < l; j++){<br>
PermissionGrant ge = grantRefCopy[j];<br>
if (ge.isPrivileged()){<br>
if (ge.implies(domain)){<br>
return true;<br>
}<br>
}<br>
}<br>
/* Merge the static Permissions, check for Privileged */<br>
PermissionCollection staticPC = null;<br>
if (domain != null) {<br>
staticPC =domain.getPermissions();<br>
if (staticPC != null){<br>
Enumeration<Permission> e =
staticPC.elements();<br>
while (e.hasMoreElements()){<br>
Permission p = e.nextElement();<br>
// return early if possible.<br>
if (p instanceof AllPermission ) return true;<br>
// Only add relevant permissions to minimise
size.<br>
if (klass.isInstance(permission) || permission
instanceof UnresolvedPermission){<br>
perms.add(p);<br>
}<br>
}<br>
}<br>
}<br>
/* Check less privileged grants */<br>
for ( int j =0; j < l; j++ ){<br>
PermissionGrant ge = grantRefCopy[j];<br>
if (!ge.isPrivileged()){<br>
if (ge.implies(domain)){<br>
Collection<Permission> c =
ge.getPermissions();<br>
Iterator<Permission> i = c.iterator();<br>
while (i.hasNext()){<br>
Permission p = i.next();<br>
// Only add relevant permissions to
minimise size.<br>
if (klass.isInstance(permission) ||
permission instanceof UnresolvedPermission){<br>
perms.add(p);<br>
}<br>
}<br>
}<br>
}<br>
} <br>
return convert(perms).implies(permission);<br>
}<br>
</p>
<div class="moz-cite-prefix">On 28/04/2021 8:19 pm, Lim wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANV9dgPztVrO6Jh9gATzJrUYGxFPXgFjHVOhEC_VrLusjfUf=w@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Wed, Apr 21, 2021 at 8:38 PM Ron Pressler <a class="moz-txt-link-rfc2396E" href="mailto:ron.pressler@oracle.com"><ron.pressler@oracle.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Its current events might be not have everything you want, but will be expanded, in
part to address the functionality that will be lost with the removal of Security Manager.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I agree that monitoring needs to be improved since there is a lack of
monitoring APIs except for JFR. Until those monitoring APIs are on par
with the usage of SM "monitoring", it makes no sense to remove without
providing alternatives.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Libraries that can disable the Security Manager aren’t able to circumvent OS-level
sandboxing. If you’re not afraid of that, then they’re trusted and JFR is superior;
if they’re untrusted, then configuring the Security Manager correctly for untrusted rich
libraries is very difficult.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Since you said that it cannot circumvent OS-level sandboxing, what
will prevent those
libraries to monitor if there is JFR active and become dormant until
there is no JFR
present, then it will execute the malicious behavior; Or, the library
attempts to hide
or render the JFR useless so that it will not be recorded and noticed?
On Wed, Apr 21, 2021 at 8:55 PM Ron Pressler <a class="moz-txt-link-rfc2396E" href="mailto:ron.pressler@oracle.com"><ron.pressler@oracle.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">For rich libraries and applications, your best bet is an OS-level sandbox. The Security Manager
might give you a false sense of security.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes, OS-level sandbox is good but can it be scalable for many types of end
users that have different OS and hardware environments? In addition, how many
end users out there have used sandbox to isolate their desktop applications
except if the program has built-in sandbox such as web browsers? Programs
such as Docker does not count.
</pre>
</blockquote>
</body>
</html>