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
