Just thought I'd share some thoughts around a couple of statements in
JEP 411:
*|java.security.{AccessController, AccessControlContext,
AccessControlException, DomainCombiner}|* — 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.
*|javax.security.auth.SubjectDomainCombiner|* and
*|javax.security.auth.Subject::{doAsPrivileged, getSubject}|* — APIs
for user-based authorization that are dependent on Security Manager
APIs such as |AccessControlContext| and |DomainCombiner|. We plan to
provide a replacement API
<https://bugs.openjdk.java.net/browse/JDK-8267108> for
|Subject::getSubject| since it is commonly used for use cases that
do not require the Security Manager, and to continue to support use
cases involving |Subject::doAs| (see below
<https://openjdk.java.net/jeps/411#subject-doas>).
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.
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.
They are also a standard API for an authorization layer, for those
wishing to re-implement it.
Just performed a search for java.security.AccessController on GitHub,
got 1,398,418 results for Java:
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
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.
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java
--
Regards,
Peter
On 3/08/2021 11:30 am, Peter Firmstone wrote:
Thanks Ron,
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.
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.
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.
Just curious, when using Agents, what are the recommendations for line
numbers in code, for exceptions etc, how are these affected when
instrumenting?
Quite happy to contribute time to adding hooks and removing other
components.
Regards,
Peter.
On 2/08/2021 9:00 pm, Ron Pressler wrote:
Our path to making Java more secure is, indeed, similar to what
you’re proposing.
The general direction is that the application, rather than the
libraries, will have the final say on security-sensitive capabilities.
Just as strong encapsulation is now on by default, other things, such
as native code, some dynamic Agent capabilities, and
perhaps others, will likely require explicit permission by the
application on the command line. I don’t know the details about
management, but I believe that remote management requires explicit
permission already.
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
what’s restricted is the ability to manipulate it (without
permission) to do something else through transformation or
circumvention of its declared API.
The default security policy today is already more restrictive than it
was a couple of versions ago, and we expect it to become
even more restrictive.
— Ron
On 2 Aug 2021, at 11:33, Peter Firmstone
<peter.firmst...@zeus.net.au> wrote:
Hello Andrew,
I think you may be misinterpreting my comment, let me clarify:
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. :)
For example, the permissions granted in this policy file:
https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new__;!!ACWV5N9M2RV99hQ!cVJkwzysH02ZFZWT3rnO_o5viWUCBTm9nnM50QaJ5G9hsg9B3p2naDVYknIrqSNURQ$
Ensure that anything that isn't specifically granted, is switched
off, eg agents, management, etc.
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.
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.
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?
We already know de-serialization can be switched off from the
command line using: -Djdk.serialFilter=!*,
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.
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.
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.
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?
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.
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.
Regards,
Peter.
On 2/08/2021 7:17 pm, Andrew Dinn wrote:
On 01/08/2021 15:28, Uwe Schindler wrote:
I'm working on the assumption that OpenJDK will close any
external holes currently defended by permission checks. It would
be good if the JDK was secure by default, with properties
required to be set for allowing such things as agents,
management, parsing xml and serialization.
You need to stop repeating this canard. There is no absolute need
for OpenJDK to retain a security mechanism to deal with problems
that for almost every use case are better solved by using
non-OpenJDK alternatives (such as OS security measures). Indeed,
it's the other way round: there is an imperative for the project to
spend precious resources on alternative capabilities (not
necessarily security related).
Sorry, as another open source project affected by the stupid JEP 411
desaster I would like to fully confirm to EVERYTHING that Peter said.
It is not a canard, it is the reality and I am really disappointed
what happened.
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.
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.
I believe Alan has answered your rather speculative follow-up
comments so I'll rest on that clarification.
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No.
03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
