<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Just thought I'd share some thoughts around a couple of
statements in JEP 411:</p>
<blockquote>
<p><strong><code>java.security.{AccessController,
AccessControlContext, AccessControlException,
DomainCombiner}</code></strong> — The primary APIs for the
access controller, which is the default implementation to which
the Security Manager delegates permission checks. These APIs do
not have value without the Security Manager, since certain
operations will not work without both a policy implementation
and access-control context support in the VM.</p>
<p><strong><code>javax.security.auth.SubjectDomainCombiner</code></strong>
and <strong><code>javax.security.auth.Subject::{doAsPrivileged,
getSubject}</code></strong> — APIs for user-based
authorization that are dependent on Security Manager APIs such
as <code>AccessControlContext</code> and <code>DomainCombiner</code>.
We plan to provide <a
href="https://bugs.openjdk.java.net/browse/JDK-8267108">a
replacement API</a> for <code>Subject::getSubject</code>
since it is commonly used for use cases that do not require the
Security Manager, and to continue to support use cases involving
<code>Subject::doAs</code> (see <a
href="https://openjdk.java.net/jeps/411#subject-doas">below</a>).</p>
</blockquote>
<p>We can still use these without an SM, Policy or Permissions for
authorization decisions, as mentioned previously I'd replace the
inherited thread context with an unprivileged context, and also
allow the stack walk to be disabled for people only using Subject.<br>
</p>
<p>The advantage of retaining these methods, is that where these are
used to preserve context for establishing TLS and Kerberos
connections, they continue to function, even without SM or policy.</p>
<p>They are also a standard API for an authorization layer, for
those wishing to re-implement it.<br>
</p>
<p>Just performed a search for java.security.AccessController on
GitHub, got 1,398,418 results for Java:<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/search?l=Java&o=desc&p=3&q=java.security.AccessController+extension%3A.java+language%3AJava+language%3AJava+language%3AJava+language%3AJava&s=indexed&type=Code">https://github.com/search?l=Java&o=desc&p=3&q=java.security.AccessController+extension%3A.java+language%3AJava+language%3AJava+language%3AJava+language%3AJava&s=indexed&type=Code</a><br>
</p>
<p>An example of how DomainCombiner provides access to the
underlying ProtectionDomain's on the stack. We don't need to call
ProtectionDomain::Implies(Permission) to make authorization
decisions.<br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java</a></p>
<pre class="moz-signature" cols="72">--
Regards,
Peter</pre>
<p> </p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/08/2021 11:30 am, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:69e09a94-0717-0ac0-74c2-8b0fd78fbc78@zeus.net.au">Thanks
Ron, <br>
<br>
What we do now is dynamic, so we need to figure out how to
replicate that post SM. Things we don't grant dynamically are
good candidates for command line argument options. <br>
<br>
We basically authenticate, then authorize class loading
dynamically at runtime, along with other things, such as
deserialization (not to be confused with Java Serialization) and
network connections. The dynamic grants are removed by garbage
collection. Dynamic grants are probably very rare for most
developers, although OSGi also supports dynamic grants also, I had
a discussion with Peter Kriens around OSGi dynamic grants some
years ago. <br>
<br>
I am still hopeful that OpenJDK might create some hooks for us and
keep the AccessController, AccessControlContext and Subject.doAs
methods to make supporting all Java versions easier. Also
replacing thread inherited context, with an unprivileged context
would be good too. Then remove all the permission implementations
and we could use the hooks we need. The hooks could simply be an
empty static method that's not subject to change, so we can
instrument it with our own implementation and it gets optimized
out at runtime if not used by hotspot. Clearly if there are
alternative mechanisms available from the command line that we
don't need to dynamically enable, then they are preferable to
adding clutter to policy files. The existing policy provider can
be removed, so we can strip it down to just the essential minimum
components, which removes much of the testing required by OpenJDK.
<br>
<br>
Just curious, when using Agents, what are the recommendations for
line numbers in code, for exceptions etc, how are these affected
when instrumenting? <br>
<br>
Quite happy to contribute time to adding hooks and removing other
components. <br>
<br>
Regards, <br>
<br>
Peter. <br>
<br>
On 2/08/2021 9:00 pm, Ron Pressler wrote: <br>
<blockquote type="cite">Our path to making Java more secure is,
indeed, similar to what you’re proposing. <br>
<br>
The general direction is that the application, rather than the
libraries, will have the final say on security-sensitive
capabilities. <br>
Just as strong encapsulation is now on by default, other things,
such as native code, some dynamic Agent capabilities, and <br>
perhaps others, will likely require explicit permission by the
application on the command line. I don’t know the details about
<br>
management, but I believe that remote management requires
explicit permission already. <br>
<br>
I am not aware, however, of plans to restrict class loading. The
idea is that code is trusted to do what it says it does, and <br>
what’s restricted is the ability to manipulate it (without
permission) to do something else through transformation or <br>
circumvention of its declared API. <br>
<br>
The default security policy today is already more restrictive
than it was a couple of versions ago, and we expect it to become
<br>
even more restrictive. <br>
<br>
— Ron <br>
<br>
<blockquote type="cite">On 2 Aug 2021, at 11:33, Peter Firmstone
<a class="moz-txt-link-rfc2396E"
href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a>
wrote: <br>
<br>
Hello Andrew, <br>
<br>
I think you may be misinterpreting my comment, let me clarify:
<br>
<br>
I'm assuming that during the process of removal of security
manager, any external ports or process hooks that we can only
turn off now by not granting a permission will be replaced by
a command line property or something similar? Eg, Agents,
Management, etc. If this is the case, it would be nice if they
were set to off by default, such that they needed to be
enabled from the command line. It's a suggestion. So
configuration is secure by default. Eg, similar to how
OpenBSD is configured secure by default, is that something
RedHat does? I used RedHat back in the 90's, it was my first
Linux distro, on sparc. :) <br>
<br>
For example, the permissions granted in this policy file: <br>
<br>
<a class="moz-txt-link-freetext"
href="https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$">https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$</a>
<br>
Ensure that anything that isn't specifically granted, is
switched off, eg agents, management, etc. <br>
<br>
This file is generated by a policy writing tool, the comments
in the policy file, indicate the tests that were run to
generate the policy. It's important to note that we aren't
using sandboxing, or isolation, we are simply running with
privileges we don't require switched off. All network entry
points to the JVM require authentication and classes loaded,
or data parsed requires authentication first. <br>
<br>
In my software without SM, authentication isn't required, and
there are no defenses against parsing un-trusted data or
downloading and loading malicious classes. Although you've
made it clear, you think this is a /special case/ and /special
loss/ you needn't concern yourself with and that's fine,
you've made your point. <br>
<br>
In future it will not be possible to switch these features off
using policy files, so I imagine that OpenJDK must be
considering alternative methods to switch off features that
may be security sensitive? <br>
<br>
We already know de-serialization can be switched off from the
command line using: -Djdk.serialFilter=!*, <br>
<br>
However if you switch off java de-serialization, you best be
sure to initialize the serialization framework when starting
your JVM, as SM won't be there to stop it being turned back
on, if it's not used, it's not initialized, then the property
can be changed and is potentially a link in a gadget chain
attack where serialization can be re-enabled. :) Just saying.
<br>
<br>
Not sure what canard you're referring to, is the JDK config
secure by default? If so, then it won't be possible for a
malicious java attachment in an email (or an image file) to be
run inadvertently and use the attach API to steal secrets.
Although it's processor could be subject to speculative
execution attacks. <br>
<br>
A good reason to use OpenBSD (or Solaris perhaps) on Sparc for
secure systems? I know RedHat is into supporting military
application in a big way, but I'm surprised if they're not
concerned about speculative execution vulnerabilities. <br>
<br>
Speculative execution attacks will eventually be addressed in
processor architectures, they are trying, we shouldn't assume
that we don't need to program defensively because the
underlying architecture has speculative execution bugs. If we
do that, then were do we stop? <br>
<br>
Anyway, if possible I would like to get back to discussing how
to instrument the Java API using Agents, and whether we can
coordinate removal of finalizers with SM removal. <br>
<br>
Of course if you'd like to keep SM and cancel JEP 411, as Uwe
suggested, I'd support that. I'm also grateful that Uwe spoke
up, and I hope others do as well, so this topic receives
further productive discussion. It would be nice to sort the
use cases prior to SM removal. JEP 411 appears symbolic at
this stage anyway, more JEP's will be created for it's
disablement I believe. <br>
<br>
Regards, <br>
<br>
Peter. <br>
<br>
On 2/08/2021 7:17 pm, Andrew Dinn wrote: <br>
<blockquote type="cite">On 01/08/2021 15:28, Uwe Schindler
wrote: <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">I'm working on the assumption
that OpenJDK will close any <br>
external holes currently defended by permission
checks. It would <br>
be good if the JDK was secure by default, with
properties <br>
required to be set for allowing such things as agents,
<br>
management, parsing xml and serialization. <br>
</blockquote>
You need to stop repeating this canard. There is no
absolute need <br>
for OpenJDK to retain a security mechanism to deal with
problems <br>
that for almost every use case are better solved by
using <br>
non-OpenJDK alternatives (such as OS security measures).
Indeed, <br>
it's the other way round: there is an imperative for the
project to <br>
spend precious resources on alternative capabilities
(not <br>
necessarily security related). <br>
</blockquote>
Sorry, as another open source project affected by the
stupid JEP 411 <br>
desaster I would like to fully confirm to EVERYTHING that
Peter said. <br>
It is not a canard, it is the reality and I am really
disappointed <br>
what happened. <br>
</blockquote>
Sorry, Uwe, but the canard *is* right there in the comment I
quoted from Peter's email i.e. the bogus implication that
without the security manager the JDK is not 'secure by
default'. Irrespective of how useful the security manager is
to your project it is utter steer manure to claim that
without it there is a serious security hole. <br>
<br>
That's not to say different measures may need to be taken by
some applications, yours included. I'm not denying that.
However, I'm not going to back down when it comes to
objecting to the lack of proportionality in Peter's claims.
<br>
<br>
I believe Alan has answered your rather speculative
follow-up comments so I'll rest on that clarification. <br>
<br>
regards, <br>
<br>
<br>
Andrew Dinn <br>
----------- <br>
Red Hat Distinguished Engineer <br>
Red Hat UK Ltd <br>
Registered in England and Wales under Company Registration
No. 03798903 <br>
Directors: Michael Cunningham, Michael ("Mike") O'Neill <br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>