On 22/05/2021 11:58, Bernd Eckenfels wrote:
:
This whole discussion about using only secure libraries really makes
me wonder if you know the realities of modern applications with
hundreds of dependencies and the state of those, like there is still
no easy way to limit XXE in upstream xerces.
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> Von: security-dev im Auftrag von Peter
> Tribble
> Gesendet: Saturday, May 22, 2021 11:11:43 AM
> An: Ron Pressler
> Cc: Peter Firmstone ; David Black
> ; Alan Bateman ;
> security-dev@openjdk.java.
:43 AM
An: Ron Pressler
Cc: Peter Firmstone ; David Black
; Alan Bateman ;
security-dev@openjdk.java.net
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring /
restricting libraries
On Sat, May 22, 2021 at 2:12 AM Ron Pressler
mailto:ron.press...@oracle.com>> wrote:
On Sat, May 22, 2021 at 2:12 AM Ron Pressler
wrote:
> Let me be very clear: the proposers of this JEP, some of whom have worked
> on the Security Manager for the
> last twenty years, strongly believe that not only will its removal not
> harm Java’s security, but considerably
> improve it, as do
Studies, experts, meetings and academics, without practical application
of the principle of least privilege, these are meaningless. I hope
someone remembered to bring tea and scones.
My point is nothing gets done without workers. It's the Pareto
Principle or 80:20 rule. Li Gong may have
Let me be very clear: the proposers of this JEP, some of whom have worked on
the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm
Java’s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either
I had hoped by end of this discussion, that there would at least be an
understanding of what OpenJDK is so hastily choosing to destroy.
Once it is gone, it will be irretrievable, it will never be possible to
lock down the JVM so securely again.
On 21/05/2021 11:06 pm, Ron Pressler wrote:
> On 21 May 2021, at 12:52, Peter Firmstone wrote:
>
> It's quite clear this will be pushed through anyway,
>
No, not *anyway*, but given the fact that the community consists of millions of
users, this
proposal has been well-publicised, only very few people have voiced objections,
fewer
On 21/05/2021 9:14 pm, Ron Pressler wrote:
On 21 May 2021, at 11:29, Peter Firmstone wrote:
Can you share this list please? If I see anything missing I can add it for
you.
No, because this might give the false impression that this is a debate.
It's quite clear this will be pushed
> On 21 May 2021, at 11:29, Peter Firmstone wrote:
>
>
> Can you share this list please? If I see anything missing I can add it for
> you.
No, because this might give the false impression that this is a debate. In a
community
of millions, almost no decision will be universally accepted.
On 21.05.2021 03:40, Peter Firmstone wrote:
If there are those of us who wanted to maintain a fork of Java 17,
focused on security, we could backport new features after they've been
reviewed for security.
Would we be welcomed to do that here? Otherwise is it something we
should do on
On 21/05/2021 6:58 pm, Ron Pressler wrote:
These are just opinions, it's nice to have them, but they're not
helping. I think you'll find usages of SecurityManager api's are far
more widespread than your opinion suggests, but that's just my
opinion too lol.
I guess you could say they’re my
> On 21 May 2021, at 04:55, Peter Firmstone wrote:
>
>
> Yes everything is a compromise and there are trade-offs. The way I see it,
> the cheapest way to maintain security is to find others who share a common
> pain point is to maintain a copy of OpenJDK focused on security. We can
>
On 18/05/2021 10:09 pm, Ron Pressler wrote:
On 18 May 2021, at 12:27, Peter Firmstone wrote:
However I disagree that the Principle of least privilege is wrong headed, I
think you've been discussing sandbox concepts with the experts and they're
going to tell you that's a bad idea. But
If there are those of us who wanted to maintain a fork of Java 17,
focused on security, we could backport new features after they've been
reviewed for security.
Would we be welcomed to do that here? Otherwise is it something we
should do on GitHub?
Cheers,
Peter.
On 21/05/2021 11:25 am,
On Thu, 20 May 2021 at 21:27, Andrew Dinn wrote:
>
> 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
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
On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and
On Tue, 18 May 2021 at 22:24, Ron Pressler wrote:
>
>
> > On 18 May 2021, at 07:10, David Black wrote:
> >
> >
> > I hope you aren't being rude on purpose by continuing to 1) top post
> > and 2) not ignore various parts of my emails.
> >
>
> This isn’t a debate forum. We’re trying to collect
> On 18 May 2021, at 07:10, David Black wrote:
>
>
> I hope you aren't being rude on purpose by continuing to 1) top post
> and 2) not ignore various parts of my emails.
>
This isn’t a debate forum. We’re trying to collect information, not
to convince every last person. I respond to what I
> On 18 May 2021, at 12:27, Peter Firmstone wrote:
>
>
> However I disagree that the Principle of least privilege is wrong headed, I
> think you've been discussing sandbox concepts with the experts and they're
> going to tell you that's a bad idea. But the two aren't the same, one is
>
On 18/05/2021 8:49 pm, Ron Pressler wrote:
On 18 May 2021, at 03:39, Peter Firmstone wrote:
Is it also possible to consider directing file access and network access
through single points of access? This will simplify the process so we don't
need to scour the entire codebase for
> On 18 May 2021, at 03:39, Peter Firmstone wrote:
>
>
> Is it also possible to consider directing file access and network access
> through single points of access? This will simplify the process so we don't
> need to scour the entire codebase for usages.
>
Of all your suggestions, I
Because people have been treating it like a sandbox.
Since it will take a number of years, can we at least consider my
proposal and give it a try? It may reduce the burden in the interim.
So this step deprecates it for removal, can we create a JEP for
replacing the SecurityManager with
On 18/05/2021 08:36, Peter Firmstone wrote:
:
It's a perception issue, I understand, but we can fix that far less
painfully.
With respect, I don't see a viable route here. SM/AccessController and
most of that security architecture has been an albatross around our
necks for years. This
On 18/05/2021 4:10 pm, Alan Bateman wrote:
On 18/05/2021 03:39, Peter Firmstone wrote:
:
Yes, I realize that, it is my understanding that because this is a
security concern, it is not something the community is allowed to
provide support for at OpenJDK, hence my suggestion to Alan, to
On 18/05/2021 03:39, Peter Firmstone wrote:
:
Yes, I realize that, it is my understanding that because this is a
security concern, it is not something the community is allowed to
provide support for at OpenJDK, hence my suggestion to Alan, to make
it possible for this to happen by changing
On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and
> On 18 May 2021, at 01:11, Peter Firmstone wrote:
>
> Your ideas are great in theory, in practice, the problem with your Agent
> proposal is every JVM release needs to be reviewed, and we have to review
> Java's internal implementation code, and understand it in order to instrument
> it.
We can call any mechanism that might impose restrictions a mitigation, but that
doesn’t mean that any mechanism is worth its cost. I believe that the evidence
gathered over the past few decades shows that attempting to assign different
permissions to code of different origin in the same process
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to
review Java's internal implementation code, and understand it in order
to instrument it. But I do appreciate you took the time to do your
homework to
> On 17 May 2021, at 21:46, Peter Firmstone wrote:
>
>
> Yes, you are talking about those who maintain and develop OpenJDK, but this
> is only a small proportion of the overall Java developer ecosystem.
Not at all. I’m talking about the millions of developers who don’t get what
they
On 18/05/2021 12:25 am, Ron Pressler wrote:
On 17 May 2021, at 13:47, Peter Firmstone wrote:
It is a foundational feature, it has a significant impact on those who adopted
it.
True. But the problem is that it also has a significant impact on those who
didn’t.
Yes, you are talking
> On 17 May 2021, at 13:47, Peter Firmstone wrote:
>
> It is a foundational feature, it has a significant impact on those who
> adopted it.
True. But the problem is that it also has a significant impact on those who
didn’t.
>
>
> This is an existing system, your arguments are not
Some quick clarifications, I'll try to reply properly in the next few days.
On 17/05/2021 9:29 pm, Ron Pressler wrote:
On 17 May 2021, at 06:19, Peter Firmstone wrote:
In versions of Java, without a security manager, the third party service
provider will have AllPermission, and the user
I would say that trying to mitigate attacks on vulnerabilities in trusted code
based on specific code paths is
not recommended. You’re trying to preemptively defend agains something complex
— a security bug — with
another complex mechanism. Even if you do happen to defend against a particular
> On 17 May 2021, at 06:19, Peter Firmstone wrote:
>
>
> In versions of Java, without a security manager, the third party service
> provider will have AllPermission, and the user will have restricted
> permissions (if we still have some form of user Permission based access
> control).
Auftrag von Peter
Tribble
Gesendet: Thursday, May 13, 2021 9:25:25 AM
An: Ron Pressler
Cc: Alan Bateman ; Peter Firmstone
; security-dev@openjdk.java.net
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring /
restricting libraries
On Wed, May 12, 2021 at 10:49 PM Ron Pressler
> On 13 May 2021, at 03:11, David Black wrote:
>
>
> This seems somewhat more useful than 1 & 2 but imho it would be better to be
> able to perform checks/grant access on a call stack basis.
This is an important point we’re trying to get across. The very reason the
Security Manager was
On Wed, May 12, 2021 at 10:49 PM Ron Pressler
wrote:
>
> > On 12 May 2021, at 22:41, Peter Tribble wrote:
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are
P.S.
Sorry, I just realised I used the word “process” in 1 and 2 with different
meanings. In 1 I meant an
OS process running Java; in 2 I merely meant a Java mechanism (as opposed to an
OS mechanism).
> On 12 May 2021, at 22:49, Ron Pressler wrote:
>
>
>
>> On 12 May 2021, at 22:41, Peter
> On 12 May 2021, at 22:41, Peter Tribble wrote:
>
>
> Let me give a concrete example:
>
> Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> We know exactly where the files are installed, so wish to allow the rendering
> routine access
> to the
On 7/05/2021 1:17 pm, Peter Firmstone wrote:
On 6/05/2021 9:46 pm, Ron Pressler wrote:
That is correct. Here is where this is mentioned for ForkJoinPool:
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html
And here it is for virtual threads
On 6/05/2021 9:46 pm, Ron Pressler wrote:
Trying to convince people, at this point, after twenty five years that the
Security Manager isn’t complicated after all might
be too little too late.
Static policy, terrible performance, no scalability at all, and the fact
that you continually
On 6/05/2021 9:46 pm, Ron Pressler wrote:
Most performance issues have to do with the stack walking at the core of the
Security Manager’s design.
I disagree, unless you can provide /evidence or context, I have not seen
any evidence for this, I've done a lot of performance testing on the
On 2021-05-06T11:46:33 +
Ron Pressler wrote:
> When the entire process has the same permissions — in line with current
> practice — there are
> superior sandboxes provided by the OS.
The issue with falling back to the sandboxes provided by the OS is that
you then have to deal with a lot of
> On 6 May 2021, at 11:26, Peter Firmstone wrote:
>
> OpenJDK seems to have assumed that no one was using SecurityManager based on
> one research report. There's a lot of closed source java code out there, I
> suspect most of our users are closed source. I don't know exactly how many
>
On Wed, May 5, 2021 at 2:13 PM Ron Pressler wrote:
>
>
> > On 5 May 2021, at 05:04, Peter Firmstone
> wrote:
> >
> > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.*
> package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API,
> java.* API's ONCE REMOVED CANNOT
> On 5 May 2021, at 05:04, Peter Firmstone wrote:
>
> A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* package
> namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, java.*
> API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED SOMETHING MAY BE
>
On 4 May 2021, at 03:49, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> wrote:
Yes, I'm sure millions of developers don't use the security infrastructure
because they only have low value data to protect, or it belongs to someone else
and developers that do, can use it incorrectly,
What you’re saying is: SM is good to help with trusted code — i.e. not the
threat that shaped its design. I’m saying,
perhaps, but other techniques are better, namely, OS-level sandboxing and deep
monitoring (based on JFR, which
will need to be extended). Why? Because the SM is a far too
Using JFR does not require that command-line option; it’s required only for
specific kinds
of use. Its current events might be not have everything you want, but will be
expanded, in
part to address the functionality that will be lost with the removal of
Security Manager. And
yes, I believe it
52 matches
Mail list logo
