Authorization layer API and low level access checks.

[Peter Firmstone]

Inline.

On 26/06/2021 1:46 pm, Peter Firmstone wrote:
>
> 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.
>

I need to make some clarifications here:

The ProtectionDomain::getPermissions() method determines whether a 
domain is privileged if it contains AllPermission.

Since future implementations might not use Permission's to determine 
privileges, and privileges may be determined by CodeSource or 
Principal's, a null CodeSource is used to indicate a domain belonging to 
the bootstrap ClassLoader.


> 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.
>

This is incorrect, as the ProtectionDomain contains a null 
PermissionCollection, my mistake.

However I still propose it be changed, due to the association of a null 
CodeSource with bootstrap ClassLoader domains.

> 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.
>
>
>>>     8. Deprecate for removal the CodeSource::implies method.
>>>
>>>     9. 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210626/2a09d791/attachment.htm>