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://github.com/pfirmstone/JGDMS/blob/trunk/qa/harness/policy/defaultsecurephoenix.policy.new
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
