> On 4 Aug 2021, at 01:19, Peter Firmstone wrote:
>
> Excellent, Ron, that's exactly what I'm after.
>
> I need to be able to implement an authorization layer on top of the JDK, but
> reach down into the JDK to use authorization to control access.
>
> Can we find out how many such checks
Maybe we need some criteria, that defines what's not easily instrumented?
On 4/08/2021 10:19 am, Peter Firmstone wrote:
Excellent, Ron, that's exactly what I'm after.
I need to be able to implement an authorization layer on top of the
JDK, but reach down into the JDK to use authorization to
Excellent, Ron, that's exactly what I'm after.
I need to be able to implement an authorization layer on top of the JDK,
but reach down into the JDK to use authorization to control access.
Can we find out how many such checks that OpenJDK is prepared to
support, then we will pick the most
> On 3 Aug 2021, at 12:50, Peter Firmstone wrote:
>
> Can you think of any workable alternative compromises?
If you mean a compromise between no access checks in the JDK and all access
checks in the JDK, then yes,
which is possibly some callbacks for a small subset of operations that perform
> On 3 Aug 2021, at 06:48, Peter Firmstone wrote:
>
>
> We can still use these without an SM, Policy or Permissions for authorization
> decisions, as mentioned previously I'd replace the inherited thread context
> with an unprivileged context, and also allow the stack walk to be disabled
> On 3 Aug 2021, at 09:39, Peter Firmstone wrote:
>
>
>
> Can you elaborate? A Runnable, similar to registering a shutdown hook?
>
Maybe, but there have been no specifics beyond saying that something like that,
and
which requires that level of effort, might, after the dust settles and
What you are proposing is:
1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.
I do not speak for those who work on the security mechanisms, but I believe
that none one of these,
even
> On 3 Aug 2021, at 02:30, Peter Firmstone wrote:
>
>
> I am still hopeful that OpenJDK might create some hooks for us and keep the
> AccessController, AccessControlContext and Subject.doAs methods to make
> supporting all Java versions easier.
When I mentioned “hooks” I was referring to
Our path to making Java more secure is, indeed, similar to what you’re
proposing.
The general direction is that the application, rather than the libraries, will
have the final say on security-sensitive capabilities.
Just as strong encapsulation is now on by default, other things, such as native
Hi.
JEP 411 says that there is a feature whose value in fulfilling its purpose no
longer justifies its high cost, and so it should be removed. What you’re saying
is, that’s true, but you should keep it, anyway. Why? Because it can be put to
some other, more modest, accidental uses.
Now, the
Can you think of any workable alternative compromises?
On 3/08/2021 9:21 pm, Ron Pressler wrote:
What you are proposing is:
1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.
I do
Wow, thanks Andrew,
There's certainly some complexity there, I appreciate your guidance.
Regards,
Peter.
On 3/08/2021 7:11 pm, Andrew Dinn wrote:
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for
line numbers in code, for
Thanks Ron, reply inline.
On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone wrote:
We can still use these without an SM, Policy or Permissions for authorization
decisions, as mentioned previously I'd replace the inherited thread context
with an
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)
On 3/08/2021 6:31 pm, Ron Pressler wrote:
On 3 Aug 2021, at 02:30, Peter Firmstone wrote:
I am still hopeful that OpenJDK might create some hooks for us and keep the
AccessController, AccessControlContext and Subject.doAs methods to make
supporting all Java versions easier.
When I
Just thought I'd share some thoughts around a couple of statements in
JEP 411:
*|java.security.{AccessController, AccessControlContext,
AccessControlException, DomainCombiner}|* — The primary APIs for the
access controller, which is the default implementation to which the
Security
Thanks Ron,
What we do now is dynamic, so we need to figure out how to replicate
that post SM. Things we don't grant dynamically are good candidates for
command line argument options.
We basically authenticate, then authorize class loading dynamically at
runtime, along with other things,
17 matches
Mail list logo
