Re: [External] : Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

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 not speak for those who work on the security mechanisms, but I believe 
that none one of these,
even in isolation, would be reasonable.

For one, even without the principle against changing the behaviour of existing 
classes in drastic
and non-trivial ways, without the use of doPrivileged in the JDK, 
AccessController would make
a bad API.
That's true, it would better if those doPrivileged calls to remain. An 
alternative I thought about if they were removed, was to treat a thread 
as privileged if all domains on the thread stack were resolvable from 
the bootstrap ClassLoader.

For another, the cost of SM isn’t in the lines of code that make up the 
AccessController implementation
but in the fact that the JDK does access checks and privileged operations in 
the first place, as those
impose a tax on everything, and also take resources away from what we believe 
is more robust and effective
security.

Yes, I realise this, however I'm not looking to replace all permission 
checks, just the most common.  Perhaps then a static method added to a 
class, without implementation would be better, in cases where it's not 
practical to instrument the JVM.  Such that it does nothing by default 
and would be optimised away by hotspot.

eg:

static instrumentGuard(String [] args) throws SecurityException{}

Thanks,

Peter.


The starting point isn’t removing the policy file implementation, but removing 
all access checks
and privileged operations from the JDK, and everything else follows from there 
(it will take a long
time until API elements are actually removed, anyway). Even if someone might 
choose to contemplate adding
callbacks to one or two I/O operations, it is not the intent for the JDK to 
participate in a general access
checking mechanism deep in its guts in addition to strong encapsulation; quite 
the opposite.


— Ron


On 3 Aug 2021, at 10:44, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:

Thanks Ron, reply inline.

On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone <peter.firmst...@zeus.net.au>
  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 for 
people only using Subject.


I think what you mean is that you can envision using the same API points for a 
different, but reasonably similar
role to the one they have. But that would mean changing the behaviour of 
existing classes, possibly making some
final classes non-final, in non-trivial ways.

I'd limit changes to:

        • Make the stack walk optional (via command line argument to disable 
it).
        • Remove Thread's inherited context, replace it with an unprivileged 
context.
This would allow us to use the API for virtual threads, eg to obtain Subject 
credentials to authenticate TLS connections.

It also means that for someone implementing guard checks, that these only need 
check the thread stack back to the last doPrivileged call, or the start of the 
thread, in the latter case it will have no privileges.  It fixes the viral 
permission check problem, usually doPrivileged calls are short and sweet.

It may require the addition of doPrivileged calls where they're currently 
missing (and should have been used), where they've been responsible for viral 
permission checks.

Just performed a search for java.security.AccessController on GitHub, got 
1,398,418 results for Java:


The plan is to degrade these into no-ops until such time as most of those 
usages disappear, not to imbue
those lines of code with new meaning. The actual removal of the API elements 
might be a long way off,
but, becoming no-ops before then, the JDK and libraries will be free to remove 
those usages.

No new meanings, the same as they have now is sufficient, just we leave the 
granularity of the checks to the developers of guards and provide a means by 
which guards can be registered for common check points that developers request 
(perhaps via a poll), rather than all existing permission check points.  
Keeping in mind that we are not trying to isolate code, but perform 
authorization access checks, as well as provide credentials for authentication.

For example, if someone is only concerned with stopping the JVM from exiting, 
then they only implement a guard for that particular hook, the actual code that 
needs to call System::exit, then calls a doPrivileged method before doing so.  
The guard need only check the domain on the stack is the one it expects, which 
could be based on Principal, CodeSource, Module or ClassLoader etc, they may 
also chose to implement something more complex.

Someone else may only be concerned with network connections, so they only 
implement and register a guard for that.

So basically we don't dictate how to implement guards or policy, we just leave 
enough in place, to ensure that a minimalist authorization access control api 
is common among all implementations on all Java versions.

It is suitable, for Subject's only or code and Subject's.

The doPrivileged call simply indicates the code is requesting to do something 
that might be privileged, or needs to provide credentials for authentication, 
as it does now, but it's the light version of the stack walk, if doPrivileged 
is not called, then the context will have an unprivileged domain on the stack 
(that initialized when Thread was created.).

It's also possible to register guards that do fine grained permission checks, 
similar to the way Java does now.

Then there's the use case, or registering no guards at all, and disabling the 
stack walk, and only using the api to obtain and preserve Subject credentials 
for authentication.

You can trust me on this one, I'm experienced with the current API and have 
pushed it to all sorts of limits.

Cheers,

Peter.