<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Ron, more discussion below.<br>
</p>
<div class="moz-cite-prefix">On 4/05/2021 9:24 am, Ron Pressler
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:A9F12F9D-4014-4738-933F-342456D6A736@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 29 Apr 2021, at 13:06, Peter Firmstone <<a
href="mailto:peter.firmstone@zeus.net.au" class=""
moz-do-not-send="true">peter.firmstone@zeus.net.au</a>>
wrote:</div>
<div class="">
<div class="">
<p class="">Is there a simpler way to limit permissions of
library code?<br class="">
</p>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Limiting permissions of library code is a spectacular idea, and
the stack-dependent deep sandbox offered by the Security Manager</div>
<div>is the most spectacular software sandbox ever created. The
problem is that while the idea is terrific, it does not seem to
work</div>
<div>in practice in any way that is simple and scalable enough to
give assured security for applications written by millions of
developers. </div>
<div>That a select few could, perhaps, use it to build secure
systems while the rest just get a false impression of security
is not a viable</div>
<div>security strategy for a popular platform.<br>
<br>
</div>
</blockquote>
<p>I would argue that it is not just an idea, that we have been able
to successfully use it in practice and have had enough time to
write tools and develop software to get around the shortcomings of
what ships by default with Java. <br>
</p>
<p>Assured security is a dreamer's paradise, one morning to awaken
with their reputation in tatters, and anyone who believes the
dreamer is similarly disillusioned, it is only possible to make
life very difficult for a determined attacker, in the hope they
will go elsewhere, it's an evolutionary arms race.</p>
<p>Developers who deploy security features, don't advertise it,
doing so provides information for would be attackers and those who
don't value security have little to protect. Therefore removing
SecurityManager will have a delayed, but unexpected response, most
developers haven't kept up with the pace of Java's development.
Most changes to date have been very positive for Java, I'm looking
forward to using the new Vector API. :)</p>
<p>Java's policy provider isn't scalable, but we shouldn't use that
as an example. I can argue that Map isn't scalable because
Hashtable isn't, while ignoring ConcurrentHashMap, I'm sure
someone would correct me.<br>
</p>
<p>Present me with an application that has trouble scaling and I
will provide SecurityManager and Policy provider implementations
that scale as well as the JVM can without a SecurityManager (once
warmed up of course). There is a negligible performance penalty,
but we're talking scalability. Happy to accept a challenge.
AccessController scales nicely. I'm sure John Rose has had
something to do with that, thank you John, it wasn't a wasted
effort.<br>
</p>
<p>The built in Java policy provider is static, therefore all
permissions need to be known prior, but this was always just a
toy, that's why there's a policy provider interface, it was
understood from the beginning. Our policy provider is dynamic,
permissions are granted at runtime. We also have a profiling tool
that creates a policy file, to be edited of course, takes out all
the guess work. I've attached two examples, took 5 minutes to
produce, easy-peasy. No I've never used the policy editing tool
lol :) That too was just a toy.<br>
</p>
<p>If you read the generated policy files attached, you'll also
notice some viral leaked permissions from Java platform code, note
that my code only uses Java's public API, no implementation API's
from jdk.internal.reflect or sun.* package namespaces are accessed
directly.<br>
</p>
<p>Yes, I'm sure millions of developers don't use the security
infrastructure because they only have low value data to protect,
or it belongs to someone else and developers that do, can use it
incorrectly, it's probably worse to do the latter, but then people
synchronize incorrectly too, but we don't remove synchronization
because of that.<br>
</p>
<p>I can say that I'm relatively confident that I use it correctly,
feel free to point out where I'm doing it wrong of course
<a class="moz-txt-link-freetext" href="https://github.com/pfirmstone/JGDMS">https://github.com/pfirmstone/JGDMS</a><br>
</p>
<p>Java's security capabilities will be reduced as a result of
SecurityManager's removal and I understand that we will no longer
be able to provide fine grained access control to sensitive data
and as security is intertwined throughout our software, that it
will have significant impact. I don't know how to replace that
functionality, I've got nothing, zero, zit, zilch, nada.</p>
<p>SecurityManager is not a theoretical feature that no one uses.</p>
<p>Lets drop the excuses that it's just a theoretical, impractical
thing that nobody uses, and say instead that we know that this
does something important, it is very powerful, it is a deployed
API that is in use, probably the only least privileged protection
domain model that really works, but we are no longer supporting it
moving forward because it is not well understood by those
maintaining it and for this reason it creates a significant
maintenance burden.<br>
</p>
<blockquote type="cite"
cite="mid:A9F12F9D-4014-4738-933F-342456D6A736@oracle.com">
<div><br class="">
</div>
<div>There are simpler, and therefore more scalably-secure ways to
either sandbox an application or restrict the Java APIs </div>
<div>accessible to untrusted plugins. I don’t believe that
semi-trusting and selectively sandboxing third-party libraries
that otherwise</div>
<div>make use of the full range of Java’s core APIs is
cost-effective and obviously secure. Companies need SMT solvers
these days to </div>
<div>check the security of policy files that are much simpler than
those that would be required to sandbox arbitrary third-party
libraries.</div>
</blockquote>
<p>Please provide some examples, migration options suggestions will
be appreciated.</p>
<p>I'm only aware of simpler and therefore less secure ways.
Scalability is not a valid argument, my implementation scales.</p>
<p>I have a profiling tool that creates policy files, then you edit
it, it's not that hard. If you don't have a tool like that, then
I can see it would be difficult, but that's why we learn to code,
to automate manual tasks? The more difficult component for
developers is preserving a subject across threads preserving
context and using privileged calls. You need that for TLS
connections. That will still have to happen after
SecurityManager's removal.</p>
<p>But if you think having to preserve a Subject between threads is
a chore, I have to preserve Subject's in threads on other JVM's.<br>
</p>
<p>The SecurityManager is only one of the tools developers must
consider for security, one must also be careful to validate
invariants during construction and avoid shared access to mutable
state.</p>
<p>I think static analysis security auditing tools would be useful,
to help developers.</p>
<blockquote type="cite"
cite="mid:A9F12F9D-4014-4738-933F-342456D6A736@oracle.com">
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">
<p class="">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>
</div>
</blockquote>
<br class="">
</div>
<div>Let's take is as a given that everyone here is interested in
adding to Java’s appeal, yet there might be disagreement over
which </div>
<div>decision would do that. Clearly, those who propose removing
the Security Manager believe it will add to Java’s appeal, if
for no</div>
<div>other reason than freeing resources to features many people
actually use, while also having a positive effect on security.</div>
</blockquote>
<p>IMHO Removal of SecurityManager will make Java less appealing to
developers because it breaks the promise that our existing
software will continue to work on later versions. See now you're
not just removing something that has a good reason for removal,
that was implemented badly, and has been replaced by a better API,
this time it's different.<br>
</p>
<p>With Serialization, we've been given more than ample notice to do
something about migrating away from it, but OpenJDK paints over it
and wastes resources adding features to putty and paint over it
some more, features that no one uses. Removing Serialization has
greater appeal :)<br>
</p>
<p>This step to remove SecurityManager is so sudden with no
replacement options, it's a broken promise to developers, who've
invested in Java.</p>
<p>Removing SecurityManager has a significantly negative effect on
security for me, just so you know. I'm not happy about its
proposed removal, but I realise there's not much I can do about
it, other than request it be done in the least painful manner.<br>
</p>
<p>I began learning Java over 20 years ago, I understand the need to
keep Java relevant, however move quickly and break things is for
younger software platforms. <br>
</p>
<p>Once SecurityManager has been removed, we will lose control over
who has access to sensitive data, so it's likely we will be stuck
on the last version of Java that provides SecurityManager. The
best way I can see for those who need the level of security that
SecurityManager provides is to maintain a community LTS edition on
OpenJDK, it will be much easier to maintain and backport security
patches if Serialization in its current form has been removed, as
it will likely have been removed from later versions of Java by
that time.</p>
<p>Lets be clear Java will no longer be able to finely control
access to sensitive data with the removal of SecurityManager. I'm
sure it will be a great bonus for OpenJDK dev's not to have to
think about, but it will impact some developers significantly, who
would like to do so with the least suffering possible.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.</pre>
</body>
</html>