[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.firmstone at 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.firmstone at 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.
>>