Request - Preparation for removal of SecurityManager

[Peter Firmstone]

Thanks Alan, comments inline below.

On 26/10/2022 11:07 pm, Alan Bateman wrote:

>
>> :
>>
>> What would make a significant difference is returning non null 
>> ProtectionDomain's for JDK modules, so we can reduce the size of the 
>> trusted computing base, to make our job smaller, hopefully that will 
>> allow focusing on placing authorization checks on the low level 
>> access to file systems and networks, which are our main concerns.
> The PD should not be null, maybe you mean the CodeSource? I think we 
> exchanged mail about this before and it might be generally useful to 
> have that. It would mean working through some issues related to patching.

Apologies, you are correct, a non-null CodeSource in system PD's.   
Thank you for remembering :)


>
>
>> :
>>
>> Do you think that tighter module boundaries will negate the need for 
>> RuntimePermission accessClassInPackage.* below?
> This is only needed when running with a SM.
>
I will need to assess each before I decide whether it warrants 
instrumenting or not.  Authorization controls aren't really the right 
tool for this, it feels like a hack, it belongs under language 
visibility controls, such as module boundaries.  In our system, 
authorization will only grant dynamic class loading to authenticated and 
authorised entities, so some of these things might belong under 
monitoring and reporting.   We can also require that dynamically loaded 
code is signed, the signer certificates for code can be communicated 
after authentication, before dynamically loading code, so we don't 
require a Certificate Authority for code certs.  We're not running 
untrusted code, but we do use PD's to represent a remote service, that 
has a presence in the local JVM, which may or may not include code.

Regards,

Peter.