On 4/15/20 3:30 AM, Weijun Wang wrote:
On Apr 14, 2020, at 1:00 AM, Sean Mullan <[email protected]> wrote:
When a SecurityManager is enabled, early code paths that involve ServiceLoader
(SL) can trigger permission checks that cause parsing of a custom policy file
to fail due to recursive processing of the policy file.
I have fixed two of these issues which can occur under the following conditions:
1. SecurityManager enabled
2. Signed JAR on the classpath
3. Policy file granting permission based on who signed jar and a keystore entry
containing the alias/key
4. Code triggering a permission check based on that grant
5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms property
in the java.security file
Parsing of the denyAfter constraint is required to verify the signed JAR, which
happens very early. This causes SL to search for a LocaleProvider to parse the
denyAfter date field which triggers a permission check, causes the policy
machinery to bootstrap, and which triggers further permission checks, etc.
The first issue is that PKCS12KeyStore is unable to verify the integrity of the keystore entry in
the custom policy file because it cannot find a "PBE" AlgorithmParameters implementation.
I fixed this by adding "SunJCE" to the list of providers that are automatically installed
during signed JAR verification.
The second issue is also in PKCS12 KeyStore where it tries to instantiate a
java.text.Collator which also uses SL and thus triggers a recursive permission
check. This was fixed by using a lazy initialization Holder pattern.
Can we just add a "collator" argument to the getPassWithModifier() method? This looks
ugly but we already have "rb".
I think that is a fine suggestion, especially since keytool and
jarsigner (the only code that calls KeyStoreUtil.getPassWithModifier())
already cache a static Collator instance. New webrev:
https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.01/
--Sean
