Brief comment on ECC attack below, the code download can be prevented by
granting DownloadPermission only to code signers and not user
principals. In this case the imposter service would only be able to
cause a signed code source to class-load. Since Java serialization is
disabled, the
Hi Martin,
Your arguments are the reasons why we use the principle of least
privilege. It creates a headache for attackers, similar to the
developer who's enabled SM for the first time and must manually add
every required permission for their software to function (who thought
that was a
David,
I understand the reasons behind seeing authorization checks at the runtime
layer as something that just adds, without any harm in the worst case (all
of this putting the maintenance cost and other arguments aside.)
My concern is more about the general security principles underpinning the
Well said, we're not trying to sandbox untrusted code. We're simply
trying to provide authorization controls on authenticated users and in
my particular case, service proxy's. It's well known the JVM can't
handle untrusted code, nor does it have well designed defenses against
parsing
On Tue, Apr 26, 2022 at 8:17 AM Mario Torre wrote:
> I think there's a difference between "perceived" security and "actual" one.
>
> The SM in today's post Spectre, Meltdown and the likes world is
> "perceived" security, which may lead to a relaxation on the security
> of other layers because at
On Mon, Apr 25, 2022 at 2:55 PM David Lloyd wrote:
> Nothing in the proposal causes splitting or delegation of
> responsibilities. It is _only_ about preserving security checkpoints
> in the JDK, which *add* a layer of checks to what the container might
> already provide. Nothing is being
On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote:
>
> On 25/04/2022 13:53, David Lloyd wrote:
> > Nothing in the proposal causes splitting or delegation of
> > responsibilities. It is _only_ about preserving security checkpoints
> > in the JDK, which *add* a layer of checks to what the
On 26/04/2022 8:10 pm, Alan Bateman wrote:
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run
://bernd.eckenfels.net
Von: security-dev im Auftrag von Peter
Firmstone
Gesendet: Tuesday, April 26, 2022 11:06:16 AM
An: security-dev@openjdk.java.net
Betreff: Re: A possible JEP to replace SecurityManager after JEP 411
On 26/04/2022 6:28 pm, Alan Bateman wrote:
> On 25
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run arbitrary code may be problematic (for the
same
: security-dev im Auftrag von Alan
Bateman
Gesendet: Tuesday, April 26, 2022 10:28:57 AM
An: David Lloyd
Cc: OpenJDK Security
Betreff: Re: A possible JEP to replace SecurityManager after JEP 411
On 25/04/2022 13:53, David Lloyd wrote:
> Nothing in the proposal causes splitting or delegat
On 26/04/2022 6:28 pm, Alan Bateman wrote:
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already provide. Nothing is being subtracted, and thus I
On 25/04/2022 10:53 pm, David Lloyd wrote:
Nothing in the proposal is intended to solve the issue of tainted
data; with or without this proposal, this is an unsolved problem.
Well, actually, the statement "this is an unsolved problem" is not entirely
true, I think we came very close to
On Fri, Apr 22, 2022 at 10:04 PM Martin Balao wrote:
> In my view, authorization decisions at higher layer generally
> have better context, are more clear and less riskier. At a lower layer
> there is more complexity and chances of both subtle combinations or
> unseen paths that may lead to check
Hi Martin,
I'm curious, you sound like you arrived at this opinion from
experience? Rather than being an upper layer only concern, my opinion
is that it requires lower layer intervention / controls, with upper
layers providing the decision making context.
My reason for asking is, we're
Hi,
On 4/8/22 11:13 AM, Sean Mullan wrote:
> In general, I think authorization is best done at a higher layer within
> the application and not via low-level SM callouts. Authorize the subject
> first and if not acceptable, prevent the operation or API from being
> called in the first place. Once
On Fri, Apr 8, 2022 at 10:14 AM Sean Mullan wrote:
>
> Ok, thanks for some clarification on the proposal.
>
> How many applications currently depend on the SM for this type of usage?
> What other alternate models have you considered?
There are some number of customers and users within our user
Ok, thanks for some clarification on the proposal.
How many applications currently depend on the SM for this type of usage?
What other alternate models have you considered?
In general, I think authorization is best done at a higher layer within
the application and not via low-level SM
Small correction:
On Fri, Apr 8, 2022 at 8:03 AM David Lloyd wrote:
> Instead the API would exist to give containers and applications an
> extra layer of authorization which does not exist today.
Of course I meant "which would not exist after JEP 411".
--
- DML • he/him
Hi Sean, thanks for replying. I'll reply inline.
On Thu, Apr 7, 2022 at 2:20 PM Sean Mullan wrote:
>
> 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).
I think we'd
Thanks for trying David. :)
Regards,
Peter.
On 8/04/2022 7:15 pm, Andrew Dinn wrote:
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
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,
Hi Sean,
In order to keep our code up to date with Java, we need to replace
access control functionality. Current advise is that we will need to
instrument the Java API, once finalizers have been removed.
The sticking point is about the retention of permission checks, which
haven't been
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
To: OpenJDK Security
Subject: A possible JEP to replace SecurityManager after JEP 411
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
Thanks for responding Peter, I've commented inline below.
On Tue, Apr 5, 2022 at 8:19 PM Peter Firmstone
wrote:
>
> Thanks David,
>
> I'd certainly support such a proposal and encourage OpenJDK to consider
> exploring it.
>
> Perhaps also consider; no privileges should be granted unless a
>
Thanks David,
I'd certainly support such a proposal and encourage OpenJDK to consider
exploring it.
Perhaps also consider; no privileges should be granted unless a
privileged call is made, this simplifies the the stack walk, such that
it's only required when a privileged call is made.
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
29 matches
Mail list logo
