Re: A possible JEP to replace SecurityManager after JEP 411
I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team
with just as much -- or possibly more -- code to maintain, test and
design around while making the behaviour under the retained API less
determinate, less reliable as a security enforcement mechanism and, in
consequence, even less likely to be used than it is already.
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
On 07/04/2022 20:19, Sean Mullan wrote:
Hi David,
Thanks for the feedback and spending some time on this proposal. Some
specific comments below.
On 4/5/22 9:52 AM, David Lloyd wrote:
Here at Red Hat there have been serious discussions about the impacts
of security manager removal on our users, and whether there is an
actual value impact, and if so, whether it can be mitigated or
reversed somehow. We are interested in exploring whether we can come
up with a way in which vendors and projects that wish to continue
using SecurityManager (or something like it) would be able to do so,
while still removing the majority of the ongoing maintenance burden
from the OpenJDK project.
Before we make a decision on whether or not we think there is
sufficient justification for working up a formal JEP, we have decided
that the best first step would be to socialize the idea in a more
general form so that we can know whether the upstream OpenJDK team
would even be amenable *at all* to the solution (or something like
it), particularly in light of the observation that previous threads
about retaining SecurityManager in any form have been looked upon in a
fairly negative light.
The primary idea behind this proposal is that, while all of the points
in JEP 411 relating to the lack of what most experts might refer to as
"actual security" are certainly true, the SecurityManager mechanism
itself does nevertheless have some inherent value. The challenge,
then, is to strike a balance between the value provided by retaining
some semblance of the mechanism versus the costs inherent in retaining
it; we would want as much of the former as possible, for as little of
the latter as possible.
With this proposal, as I understand it, the JDK would still be
responsible for maintaining and preserving essentially all of the
existing calls to the Security Manager (SM). All new code and APIs would
still need to be evaluated and determined if permission checks were
needed as well as making appropriate specification changes to note the
behavior when an SM is enabled (throwing a SecurityException, etc). Any
missing checks would need to be treated as security issues. And we would
still need to test the code and APIs to ensure that it worked properly
and complied with the API specification. This would likely mean
implementing and maintaining an internal SM implementation in OpenJDK.
The proposal also includes retaining calls to doPrivileged (but later
potentially replacing them with some other mechanism TBD). The JDK
source code includes over 1000 calls to doPrivileged. Each of these need
to be carefully reviewed to ensure that they do not contain security
issues and any new code needs to be evaluated to see if new calls to
doPrivileged are necessary.
Retaining doPrivileged (or something similar) means that there can be
domains of code with different permissions running within the VM, which
retains much of the complexity of the current SM model.
In this proposal, how privileges are established or propagated is
implementation-specific. But how could applications or libraries depend
on the APIs and still have some confidence that the code is behaving
consistently and securely?
Today, the cost of buying into the SM model is high for libraries and
applications. Not many third party libraries support the SM and have
modified their code to perform permission checks and call doPrivileged
in the right places. If there were pluggable SMs each behaving
differently, there would likely be less incentive.
Although it sounds beneficial to be able to delegate the SM
implementation to a 3rd-party, in reality, I think very few people would
take the time to implement it securely, and instead would mostly
leverage its power to do things that aren't at all security related.
Sure, removing the default SM and Policy implementation reduces the
complexity a little, but there would still be a fairly significant
maintenance overhead and an additional drawback that it would make it
more difficult for applications and libraries to depend on any type of
consistent behavior.
--Sean
So, here's the idea. It is assumed (for the sake of common
understanding) that as things stand, all of the classes and members
marked as "deprecated for removal" as a part of JEP 411 are intended
to be completely removed without replacement at the end o
Re: [External] : Re: JEP 411, removal of finalizers, a path forward.
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for line
numbers in code, for exceptions etc, how are these affected when
instrumenting?
For Byteman I use ASM to inject bytecode sequences into methods without
any (significant) modification to existing bytecodes. ASM successfully
adjusts line number info to allow for the injected code without the need
for my agent to take any action.
I also add extra exception handling around injected regions and
propagate exceptions through enclosing regions to an outer handler. ASM
updates the exception table according to where the method visitor
notifies new try and catch region boundaries while retaining the regions
determined by existing notifications.
ASM provides mechanism for more complex cases. If you are rewriting
existing bytecodes or exception regions then you can use the ASM visitor
pattern to process and then renotify both line numbers and try catch
boundaries as you visit the bytecode stream. Of course, the logic of how
to do that can be as complex as (or more so than) the rewrite logic.
n.b. Remapping exception regions at load time is tricky for two reasons.
Firstly, you cannot afford to load exception classes to investigate the
exception class hierarchy without losing the opportunity to transform
the exception class's bytecode. So, you have to identify exception
shadowing by parsing the bytecode as a resource to establish exception
super relationships. Secondly, if you tinker with or inject extra try
regions you need to a) ensure they are properly nested inside containing
try regions b) make sure that new exception exit paths out of
synchronized regions include monitorexits.
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
Re: JEP 411, removal of finalizers, a path forward.
On 02/08/2021 11:33, Peter Firmstone wrote:
I think you may be misinterpreting my comment, let me clarify:
Really? I'd suggest only if you stretch the meaning of your words beyond
their elastic limit.
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. . . .
They might be or they might not be replaced -- and, indeed, you are
welcome to help the project to make that a possibility. However, even if
they were not replaced or enabled as default behaviours the platform
would not fail to be 'secure by default'. At worst, it might be lacking
belt and braces when it comes to available means for enforcing some
specific forms of control over execution -- controls that can be used to
resolve some security problems, but not exclusively. Yet, you keep using
language that implies the loss of the security manager is a significant
threat to the security of OpenJDK/Java.
Claiming now that all you meant was that you would like to have APIs
that give you similar mechanisms to what is being removed does not was
and will not validate the use of such exaggerated language. Nor do such
statements give anyone confidence that you are able to identify clear
and compelling requirements and assess the effort that might be needed
to satisfy them and maintain an implementation.
So, maybe you should just stop making out that your concerns are a major
problem to most developers and that they threaten the integrity of the
platform and instead concentrate on identifying simple and maintainable
APIs that we can feasibly add to OpenJDK without incurring an
unjustifiable maintenance burden.
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
Re: JEP 411, removal of finalizers, a path forward.
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
Re: JEP 411, removal of finalizers, a path forward.
On 01/08/2021 03:14, Peter Firmstone 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).
The fact that your software can no longer profit from this specific
mechanism is a /special case/ which means any loss incurred is a
/special loss/ not a general one. Users who rely on your software for
the security guarantees you claim it provides may well no longer be able
to do so once this mechanism is removed. However, claiming that this
implies Java is no longer secure by default is a /gross/
misrepresentation of what is at stake.
Java can be used perfectly well to implement secure applications without
the security manager. That's evidenced by two facts: on the one hand
experience has shown that most programs that rely on the security
manager are not actually more secure because of using it; on the other
hand there are many highly secure Java programs out there in the field.
The fact that your software will no longer provide a specific route to
implementing a certain type of security capability may be a great loss
to you but it is not a significant loss, never mind some absolute loss
in kind, to Java and Java application developers. I recommend you stop
repeating this distorted opinion. It's only effect will be squander the
goodwill of those currently trying to help you, people whose driving
interest is nothing other than to make OpenJDK a better product.
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
Re: Authorization layer API and low level access checks.
OHi Peter,
n 23/06/2021 04:02, Peter Firmstone wrote:
1. StackWalker - Can stack walker be back ported to Java 8?
The right place to ask about this is the jdk8u updates project list.
However, you probably don't need to ask there because the answer is
almost certainly going to be a very loud no.
JDK8u is in long term maintenance mode. The goal of the updates project
for that release is to fix security issues and critical bugs *and
nothing else* so that existing deployments remain stable as far as
possible. Except when required to meet those goals backporting of new
functionality is done only under exceptional circumstances.
The only recent examples of new function backports that I am aware of
have involved merging up functionality from downstream releases in order
to 1) unify the platform and 2) enable downstream contributors to help
to maintain a single, standard release i.e. highly exceptional cases
where there was a problem for existing users. Your request, by contrast,
is exactly the sort of case that maintainers are trying to avoid -- it
will introduce change with no gain and the potential of breakage for the
vast majority of users.
If you want to deal with deployments pre and post removal of the
Authorization support that you currently rely on I suggest you consider
doing that by using a multi-release implementation and package it using
the multi-release jar format. If you don't like the idea of
multi-release jars you can still implement a standard jar format
solution using a provider model. However, you will still need to build
the alternative provider jars using the relevant JDK releases so that
different providers can rely on different JDK capabilities..
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
Re: Authorization Layer post JEP 411
On 03/06/2021 08:28, Peter Firmstone wrote:
Apologies, I meant when compiled to native code, when you ship native
binaries.
I'm not sure what you mean here. Are you talking about native binaries
as generated by the GraalVM Native Image Generator? If you are
suggesting there is a disparity in behaviour between any such image and
the original app running on the JVM - whether specifically with respect
to how the stack walk APIs operate or more generally -- then I'd be
very interested to know the full details.
Note however that were any such disparity to exist then there is no onus
on the OpenJDK project to react to it. OpenJDK is based on a well
defined standard and is not beholden to decisions made by other projects
about how to translate Java code into a delivered executable.
Having said that, if it's necessary to use StackWalker behind
AccessController.doPrivileged going forward then lets do so, and maybe
the native binary is a later feature.
Hopefully my proposal is getting some consideration.
If you are proposing a change to Java then I think recommend that you
propose it relative to the current reference implementation of the Java
Language (and JVM) standards i.e. OpenJDK.
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
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 18/05/2021 23:06, David Black wrote:
I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage proposals that mean
that people who want to do 4, who implement further security hardening
where others seemingly shy away, can continue to do 4.
Please don't do that. The cost Ron is talking about is not to "Oracle".
It is a cost to the OpenJDK project as a whole.
Likewise, the lack of project team interest in maintaining the security
manager and self-evident interest in applying resources to providing
other, more valuable Java capabilities is not simply restricted to
"Oracle" project members.
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
