On 26/06/2023 00:15, Peter Firmstone wrote:
Will the removal process be traceable using a bug ID or JEP, until
it's completely removed, rather than bit rotted out over time?
Details TBD but there will be a JEP as it a significant change.
-Alan
After much thought and consideration our best
Will the removal process be traceable using a bug ID or JEP, until it's
completely removed, rather than bit rotted out over time?
After much thought and consideration our best option is to maintain our
own build, by maintaining patches against the upstream OpenJDK build,
this will allow us to
> On 23 Jun 2023, at 08:16, Peter Firmstone wrote:
>
>
> When someone comes up with a simpler design, I'm all up for the effectiveness
> challenge, I'm pretty sure that whatever it is, we'll blow it away both on
> performance and effectiveness, we've had years to perfect it, but I would
> a
On 23/06/2023 11:06 am, Ron Pressler wrote:
On 22 Jun 2023, at 23:50, Peter Firmstone wrote:
If you are able to share, I'd be interested to learn about challenges you had
with SM, if we one day have the opportunity to reimplement it, the lessons
might be valuable, so we can avoid the sam
> On 22 Jun 2023, at 23:50, Peter Firmstone wrote:
>
>
> If you are able to share, I'd be interested to learn about challenges you had
> with SM, if we one day have the opportunity to reimplement it, the lessons
> might be valuable, so we can avoid the same mistakes.
Much of the effort has
ler
*Sent:* Wednesday, June 21, 2023 12:52 PM
*To:* Peter Firmstone
*Cc:* c...@anastigmatix.net ;
security-dev@openjdk.org
*Subject:* Re: [External] : Re: PrivilegedAction et al and JEP411
> On 21 Jun 2023, at 01:36, Peter Firmstone
wrote:
>
>
> I'm just disappointed that we are b
rom: security-dev on behalf of Ron Pressler
Sent: Wednesday, June 21, 2023 12:52 PM
To: Peter Firmstone
Cc: c...@anastigmatix.net ; security-dev@openjdk.org
Subject: Re: [External] : Re: PrivilegedAction et al and JEP411
> On 21 Jun 2023, at 01:36, Peter Firmstone wrote:
>
>
> I
> On 22 Jun 2023, at 02:21, Peter Firmstone wrote:
>
> This discussion on OpenSearch is worth a read.
> https://github.com/opensearch-project/OpenSearch/issues/1687
The cross-platform API (SystemCallFilter) is something that looks like it would
make for an interesting separate library.
I a
On 21/06/2023 8:52 pm, Ron Pressler wrote:
On 21 Jun 2023, at 01:36, Peter Firmstone wrote:
I'm just disappointed that we are being prevented from reimplementing a
replacement authorization layer in Java, without any compromise from OpenJDK
it's not possible. We at least need to retain s
> On 21 Jun 2023, at 01:36, Peter Firmstone wrote:
>
>
> I'm just disappointed that we are being prevented from reimplementing a
> replacement authorization layer in Java, without any compromise from OpenJDK
> it's not possible. We at least need to retain some kind of privilege action
> me
On 20/06/2023 9:08 pm, Andrew Dinn wrote:
We have already provided better ways to address security concerns
Maybe the documentation hasn't been updated, I can't find the "better
ways" to do authorization, unless it's not considered a security concern
any more. But I don't feel like arguing
On 20/06/2023 9:04 pm, Ron Pressler wrote:
On 20 Jun 2023, at 06:26, Peter Firmstone wrote:
Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's
just OpenJDK is also undoing years of tested and hardened API's,
You probably meant that as a bad thing, but I read it as
On 20/06/2023 11:27, Peter Firmstone wrote:
I understand the economic motivations behind the decision, call that a
corporate plot if you like. Do I have to be happy about it? No.
Well, no, actually ... I won't call it that. Indeed, you are signally
missing (or evading) my point with that comm
> On 20 Jun 2023, at 06:26, Peter Firmstone wrote:
>
> Don't get me wrong, it's good that OpenJDK is improving encapsulation, it's
> just OpenJDK is also undoing years of tested and hardened API's,
You probably meant that as a bad thing, but I read it as thank you for serving
your users! Our
I understand the economic motivations behind the decision, call that a
corporate plot if you like. Do I have to be happy about it? No.
There is no practical way to reimplement authorization, at the
application level, without some underlying support from the JVM, if I
remove it from my appli
On 19/06/2023 23:44, Peter Firmstone wrote:
OpenJDK dev's have worked hard to improve encapsulation, however OpenJDK
has made it abundantly clear, that even if the community could maintain
and improve a feature, corporate has the final say and will do whatever
they want anyway, as much as I app
Don't get me wrong, it's good that OpenJDK is improving encapsulation,
it's just OpenJDK is also undoing years of tested and hardened API's,
that we're expected to come up with DIY solutions for, with zero care
from OpenJDK and some very bad examples of alternative solutions, not to
mention a c
It looks like you got their attention. :)
Although we've had the assurance from OpenJDK that we could implement an
authorization framework using StackWalker and agents, I've found it's
not feasible, since privileged actions will be lost and there will be no
support from OpenJDK, it would destr
> On 19 Jun 2023, at 12:48, Peter Firmstone wrote:
>
> For most Java developers, and Jvm users, it means that all Java bytecodes
> need to be audited and trusted,
That has always been the case for *server* applications because SecurityManager
has never protected against some of the most com
On 2023-06-19 07:48, Peter Firmstone wrote:
Having an authorization layer, made it more difficult for attackers
to gain access to sensitive information, such as properties, especially
if you were using policy files with least privilege principles.
Agreed. I hope it did not seem as if my recent
For most Java developers, and Jvm users, it means that all Java
bytecodes need to be audited and trusted, to be fair OpenJDK provide
flight recorder and other tools. The drawback of this approach, is that
Java allows dynamic code downloads, attackers will attempt to introduce
gadgets, or injec
On 2023-06-18 08:15, Alan Bateman wrote:
Once the SM operating mode goes away then I would expect most usages of
privileged actions in the JDK can be removed. Leaving them for an
"authorization layer" to instrument would be misleading. Existing
usages will quickly bit rot. It would also be a ta
Thank you for clarifying.
OpenJDK advised us it was possible to implement a new Authorization
layer above the JVM, but without any suitable hooks from within the JVM,
it's not feasible.
We will support Java until the last version we can, it's not possible
for us to re-secure our software on
On 18/06/2023 12:52, Peter Firmstone wrote:
Thanks Alan,
Personally, I would hope that nothing happens until after Java 21,
time is precious, we'll need all the time we can get.
I was hoping, that all privileged actions might be retained
indefinitely, so that we may instrument them.
Once
Thanks Alan,
Personally, I would hope that nothing happens until after Java 21, time
is precious, we'll need all the time we can get.
I was hoping, that all privileged actions might be retained
indefinitely, so that we may instrument them. Perhaps in future they
may also have other uses wi
On 18/06/2023 02:28, Peter Firmstone wrote:
Curious to know OpenJDK's plans for removal of
AccessController::doPrivileged calls?
As JEP 411 alludes, the likely next step for this one is to degrade it
so that it just runs the action. This should be transparent to most
code, esp. library code
Curious to know OpenJDK's plans for removal of
AccessController::doPrivileged calls?
PrivilegedAction shows intent, that an action about to be executed
requires privileges.
Can OpenJDK retain instances of PrivilegedAction and
PrivilegedExceptionAction?
We can find PrivilegedAction::run in
27 matches
Mail list logo
