Access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.org.objectweb.asm")

SUMMARY: SonarQube community edition 9.4.0.54424 wouldn’t run on AmazonLinux 2 + Amazon Corretto 11

After downloading, unzipping and configuring the sonarqube-9.4.0.54424.zip for my SonarQube installation, the included elasticsearch would not run properly and I’d receive the following errors:

 ==> es.log <==
 2022.04.21 12:21:52 WARN  es[][stderr] java.lang.reflect.InvocationTargetException
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesvi sorImpl.java:43)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:535)
 2022.04.21 12:21:52 WARN  es[][stderr] Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.org.objectweb.asm")
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/java.security.AccessController.checkPermission(AccessController.java:897)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1238)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:174)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at Log4jHotPatch.asmVersion(Log4jHotPatch.java:71)
 2022.04.21 12:21:52 WARN  es[][stderr] 	at Log4jHotPatch.agentmain(Log4jHotPatch.java:93)
 2022.04.21 12:21:52 WARN  es[][stderr] 	... 6 more

 ==> sonar.20220421.log <==
 Exception in thread "Attach Listener" Agent failed to start!

This was exactly similar to:

I am running on AmazonLinux 2 and a fresh installation of Amazon Corretto:

[sonar@sonar logs]# rpm -qa | grep corretto
java-11-amazon-corretto-headless-11.0.14+10-1.amzn2.x86_64
[sonar@sonar logs]#

Based on the comments in the other post, I suspect the root cause is the log4j patch installed by AmazonLinux 2:

[sonar@sonar logs]# rpm -qa | grep cve
log4j-cve-2021-44228-hotpatch-1.1-16.amzn2.noarch
[sonar@sonar logs]#

This is undoubtably not the correct way to get it working, but I was able to overcome this error and get SonarQube functioning by adding the following lines to /usr/lib/jvm/java-11-amazon-corretto.x86_64/lib/security/default.policy:

// perms needed by sonarqube ES
grant {
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.org.objectweb.asm";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
};

I’m sure this will be overwritten by Corretto updates and may have security implications.

But hopefully this might also help others struggling to get it running and hope this might help the SonarQube team better understand where to focus their efforts and lead to a more seamless way to get SonarQube running on AmazonLinux 2 with Amazon Corretto 11.

-RP

3 Likes

Thanks for posting this solution!

Rather than modifying the default.policy file, I’ve taken the security.policy from the Elasticsearch repo and added the following to the existing grant section at the end of the file (right before the last } character):

  // perms needed by sonarqube ES
  permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.org.objectweb.asm";
  permission java.lang.RuntimePermission "accessDeclaredMembers";

I assume that the policy from Elasticsearch is the right one - I found it in this blog post: Mitigate Log4j / Log4Shell in Elasticsearch (CVE-2021-44228).

I then changed sonar.properties to use this security policy in the Elasticsearch process:

sonar.search.javaAdditionalOpts=-Djava.security.policy=/opt/sonarqube/elasticsearch/config/security.policy

I did this because I figured that it was less likely to get overwritten by updates in the future and was easier to manage from my Ansible playbook. I’m posting here in case it helps someone else in the future.

1 Like

Very nice! I’m going to backfill this…

-RP