Authorization layer API and low level access checks.

[Peter Firmstone]

Inline below.

On 26/06/2021 1:11 pm, Peter Firmstone wrote:
>
> One more proposed change inline:
>
> On 26/06/2021 12:58 pm, Peter Firmstone wrote:
>>
>> Summary of Proposed Changes:
>>
>>  1. GuardFactory & GuardFactorySpi to provide hooks for authorization
>>     checks without SecurityManager or Policy. (Note GuardFactory
>>     should never return null and instead return a no-op Guard that
>>     hotspot can optimize out.
>>  2. Existing Permission implementations to be obtained using
>>     GuardFactorySpi implementations, until their removal.  Note that
>>     when SecurityManager is stubbed out and Permission
>>     implementations are deprecated for removal, these should no
>>     longer be provided by default, but instead need to be enabled by
>>     entries in the java.security config file, in preparation for
>>     their removal.
>>  3. JDK code, no longer call Permission implementations directly,
>>     instances obtained using GuardFactory, only when enabled in the
>>     java.security configuration file.
>>  4. Threads (system and virtual) updated to use a singleton
>>     *unprivileged* AccessControlContext, instead of inherited
>>     AccessControlContext, this is more appropriate for Executors, the
>>     original inherited context was designed before Executors were
>>     introduced.
>>  5. Deprecation for removal of all Permission implementations from
>>     the JDK platform.   The existing implementations of Permission
>>     introduce unnecessary complexity; they lack sufficient
>>     flexibility resulting in a proliferation of Permission grants
>>     required in policy files and some make blocking network calls.
>>  6. Introduce a system property to change AccessController default
>>     behaviour, disable the stack walk by default, but allow it to be
>>     re-enabled with a system property, replace the stack walk array
>>     result of ProtectionDomains with an *unprivileged*
>>     AccessControlContext, the SubjectDomainCombiner can replace it
>>     with a, AccessControlContext containing a single element array,
>>     containing one ProtectionDomain with Principals.
>>  7. AccessController::doPrivileged erases the DomainCombiner by
>>     default, deprecate these methods, retain doPrivilegedWithCombiner
>>     methods that preserve the SubjectDomainCombiner.   Developers
>>     should replace their doPrivileged methods with
>>     doPrivilegedWithCombiner
>>

Just thinking out loud, it's possible someone might want to do perform 
some task without privileges enabled, that is without the Subject's 
principal's.   In a system that grants privileges to code and 
principals, this is generally unnecessary, as grants are made to the 
combination of code and principals.  However while using the 
doPrivileged methods is possible, to remove privileges, it would be 
better to provide an AccessController::doUnprivileged method instead, 
which erase the DomainCombiner and use an *unprivileged* 
AccessControlContext.

Since the doPrivileged methods are utilised by other methods in 
AccessController, they should be made private when finally deprecated 
for removal.

I have also just noticed a bug in AccessController.AccHolder.innocuousAcc.

The innocuous AccessControlContext, is intended to have no permission, 
hence it is constructed using the two argument ProtectionDomain 
constructor, which causes ProtectionDomain to not consult the Policy.

However, if a user obtains this ProtectionDomain and asks the Policy for 
the ProtectionDomain's permission's by calling 
Policy::getPermissions(ProtectionDomain), the Policy will return 
AllPermission.

It is generally understood that a ProtectionDomain with a null 
CodeSource is a system ProtectionDomain loaded by the bootstrap ClassLoader.

I propose that innocuous AccessControlContext instead be given a 
ProtectionDomain, with a non-null CodeSource, which has a null URL.  
This is also considered by the Policy to be unprivileged.


>>  1. Deprecate for removal the CodeSource::implies method.
>>  2. Give unique ProtectionDomain's with a meaninful CodeSource to
>>     Java modules mapped to the boot loader, rather than using a
>>     Shared ProtectionDomain with a null CodeSource.
>>
>     10. Deprecate for removal AccessController::checkPermission and 
> AccessControlContext::checkPermission methods.
>
>     11. Undeprecate AccessController, AccessControlContext, 
> DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while 
> deprecating for removal methods stated in items above.
>
>> To clarify what an *unprivileged* AccessControlContext is:
>>
>>     An instance of AccessControlContext, that contains a single
>>     element array, containing a ProtectionDomain, with a non null
>>     CodeSource, containing a null URL.
>>
>> Retention of AccessController, AccessControlContext, DomainCombiner 
>> and SubjectDomainCombiner and Subject::doAs methods.
>>
>> Stubbing of SecurityManager and Policy, for runtime backward 
>> compatibility. Update ProtectionDomain::implies method, to *not* 
>> consult with the Policy.  Note it's possible to get access to the 
>> ProtectionDomain array contained within AccessControlContext using a 
>> DomainCombiner.
>>
>> This is backward compatible with existing usages of JAAS and least 
>> painful method of transition for all concerned as well as allowing 
>> complete flexibility of implementation.
>>
>> Regards,
>>
>> Peter Firmstone.
>>
>> On 25/06/2021 3:59 pm, Peter Firmstone wrote:
>>> Thanks Dalibor,
>>>
>>> Would targeting Java 18 be practical?
>>>
>>> Also it won't take long to code a prototype, just not sure of the 
>>> process.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>> On 24/06/2021 9:30 pm, Dalibor Topic wrote:
>>>> On 24.06.2021 04:24, Peter Firmstone wrote:
>>>>> Thanks Andrew,
>>>>>
>>>>> For the simple case, of replacing the SecurityManager stack walk, 
>>>>> one could use reflection.
>>>>>
>>>>> Thank you for also confirming that is not possible (or at least 
>>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is 
>>>>> for JDK code to use a provider mechanism, to intercept permission 
>>>>> checks, so custom authentication layers can be implemented, this 
>>>>> could be accepted in future versions of Java, but not existing. As 
>>>>> it is said, there is no harm in asking.
>>>>
>>>> Generally speaking, adding any public APIs to a platform release 
>>>> after its specification has been published, is always going to be a 
>>>> very tall order involving the JCP, among other things. It's not 
>>>> really worth it, when other technical solutions, such as 
>>>> multi-release JARs, already exist, that alleviate the necessity.
>>>>
>>>> cheers,
>>>> dalibor topic
>>>>
> -- 
> Regards,
>   
> Peter Firmstone
> 0498 286 363
> Zeus Project Services Pty Ltd.