Request - Preparation for removal of SecurityManager

[Peter Firmstone]

Thanks Alan,

That's correct, however some parts will bit rot faster than others, 
historically some parts of the JDK are very slow to change, unless 
someone comes through deliberately removing them, which I would hope 
not, but I realise that new methods and classes might open new code 
paths that don't invoke them.

It's an additional layer of indirection that buys us some time.

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.

Basically if all our hooks are in a small number of trusted computing 
base modules, then we can authorize access for other modules, as needed, 
but no more than required, hopefully without needing to maintain hooks 
for the entire JDK codebase.

Examples for JDK modules which have non-null ProtectionDomain's:

Do you think that tighter module boundaries will negate the need for 
RuntimePermission accessClassInPackage.* below?

grant codebase "jrt:/jdk.crypto.ec"
{
     permission java.security.SecurityPermission 
"putProviderProperty.SunEC";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.jca";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.pkcs";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util.math.intpoly";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.x509";
};

grant codebase "jrt:/java.xml.crypto"
{
     permission java.security.SecurityPermission 
"putProviderProperty.XMLDSig";
     permission java.util.PropertyPermission 
"java.specification.version", "read";
};

grant codebase "jrt:/jdk.security.jgss"
{
     permission java.security.SecurityPermission 
"putProviderProperty.JdkSASL";
     permission java.security.SecurityPermission 
"putProviderProperty.SunJGSS";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
};


grant codebase "jrt:/jdk.security.auth"
{
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.krb5";
     permission java.lang.RuntimePermission 
"accessClassInPackage.sun.security.util";
     permission java.lang.RuntimePermission "getProtectionDomain";
     permission java.io.FilePermission 
"${qa.home}${/}lib${/}jiniharness.jar", "read";
     permission javax.security.auth.AuthPermission "modifyPrincipals";
     permission javax.security.auth.AuthPermission 
"modifyPrivateCredentials";
     permission javax.security.auth.AuthPermission 
"modifyPublicCredentials";
};

Regards,

Peter.

On 26/10/2022 4:24 pm, Alan Bateman wrote:
> On 26/10/2022 02:58, Peter Firmstone wrote:
>> :
>>
>> Using the existing permission check hooks in the JDK allows us to 
>> significantly speed up our development efforts.   Each time a 
>> permission check hook is removed, we will need to replace it with 
>> instrumentation.   I was hoping this could be done in a controlled 
>> manner.
>>
> The permission checks in the JDK might give you a baseline for what 
> you want to do right now but once the ability the set a SM goes away 
> then you have to assume those permission checks will rapidly bit rot 
> and be removed. The JDK code is constantly changing and features are 
> added in most releases. Most new features would have historically 
> interacted with the SM in some way. So trying to instrument everywhere 
> where a permission check might live will be a lot of work. It will 
> mean keeping up with all code changes and all new features, it will 
> give you a sensitive of the effort to keep the SM execution mode 
> working security today.
>
> -Alan