Forgot to cc.
Forwarded Message
Subject: Re: Low level hooks in JDK for instrumentation of permission
checks.
Date: Mon, 14 Jun 2021 15:13:15 +1000
From: Peter Firmstone
To: jdk-...@openjdk.java.net
Clarification, utilize java.security.Provider.
So this might
Some thoughts on hooks:
* Utilize the Service Provider API, so as not to expose jdk
implementation code. META-INF/services/java.security.Guard
* Allow existing Permission classes to remain backward compatible,
declare them as services, so that SecurityManager can be degraded as
planne
Thanks Alan,
I've been thinking that it may be preferable to have hooks that allowed
us to inject our own permission checks, rather than retaining existing
permission checks.
An implementation can override Guard::check without requiring a provider
mechanism.
The other advantage is the abil
On 10/06/2021 07:40, Peter Firmstone wrote:
Just a quick question, would it be possible that some JFR hooks might
also be useable for an authorisation layer?
JFR events can't be used to intercept/veto operations, assuming that is
what you are asking. However, it might be that JFR events are
Just a quick question, would it be possible that some JFR hooks might
also be useable for an authorisation layer?
Regards,
Peter.
On 9/06/2021 11:35 am, Peter Firmstone wrote:
Apologies in advance if this seems like paranoid security.
As you are likely now aware, we have been using Security
Thanks Alan,
You've hit the nail on the head.
In policy implementations, a null CodeSource in PD, is assigned
AllPermission. So it would require adding grant statements for these
modules in the default policy file that ships with the JVM.
I thought it's an opportunity to make ProtectionDom
On 10/06/2021 03:49, Peter Firmstone wrote:
Hi Sean,
Sorry I've confused you.
What I should have said is a ProtectionDomain with a null CodeSource.
What I mean to ask is, where ProtectionDomain is created with a null
CodeSource, in Class::getProtectionDomain() can we have CodeSource's
that r
Hi Sean,
Sorry I've confused you.
What I should have said is a ProtectionDomain with a null CodeSource.
What I mean to ask is, where ProtectionDomain is created with a null
CodeSource, in Class::getProtectionDomain() can we have CodeSource's
that represents system modules instead of null?
A
On 6/8/21 9:35 PM, Peter Firmstone wrote:
I would also like to request that all JDK modules be given
ProtectionDomain's following SecurityManager deprecation. Currently some
modules have null ProtectionDomain's to show they have AllPermission.
However we don't grant AllPermission to code in
Apologies in advance if this seems like paranoid security.
As you are likely now aware, we have been using SecurityManager a little
differently than recommended as we adapted it to our requirements.
Sometimes it's not always easy to explain or obvious why something is
done in a certain way.
10 matches
Mail list logo
