Rudder

Thanks for getting back to me.
Here's the information you asked for.

# uname -a
Linux rudder 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux

# lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 9.5 (stretch)
Release:        9.5
Codename:       stretch

# dpkg --list | grep -e rudder -e ncf
ii  ncf                              4.3.4-stretch0                 all          ncf - CFEngine framework
ii  ncf-api-virtualenv               4.3.4-stretch0                 all          ncf - CFEngine framework
ii  rudder-agent                     4.3.4-stretch0                 amd64        Configuration management and audit tool - agent
ii  rudder-inventory-endpoint        4.3.4-stretch0                 all          Configuration management and audit tool - service to receive inventory data
ii  rudder-inventory-ldap            4.3.4-stretch0                 amd64        Configuration management and audit tool - OpenLDAP
ii  rudder-jetty                     4.3.4-stretch0                 all          Configuration management and audit tool - Jetty application server
ii  rudder-reports                   4.3.4-stretch0                 all          Configuration management and audit tool - reports database
ii  rudder-server-relay              4.3.4-stretch0                 amd64        Configuration management and audit tool - Server relay package
ii  rudder-server-root               4.3.4-stretch0                 all          Configuration management and audit tool - root server base package
ii  rudder-techniques                4.3.4-stretch0                 all          Configuration management and audit tool - techniques
ii  rudder-webapp                    4.3.4-stretch0                 all          Configuration management and audit tool - webapp

# java -version
openjdk version "1.8.0_181" 
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

Some more information on that subject:

- I reproduced it on centos 7, some JVM version.
- it seems to be here:

        at com.normation.rudder.services.policies.JsEngine$SandboxSecurityManager.checkPermission(JavascriptEngine.scala:681)
        at sun.misc.URLClassPath.check(URLClassPath.java:642)
        at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1268)
        at sun.misc.URLClassPath$FileLoader.findResource(URLClassPath.java:1249)
        at sun.misc.URLClassPath.findResource(URLClassPath.java:215)
        at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
        at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
        at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:546)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at com.normation.rudder.services.policies.JsEngine$SandboxSecurityManager.checkPermission(JavascriptEngine.scala:681)
        at sun.misc.URLClassPath.check(URLClassPath.java:642)

Which correspond to code:

676    override def checkPermission(permission: Permission): Unit = {
677      if(isSandboxed.get) {
678        // there some perms which are hard to specify in that file
679        permission match {
680          // jar and classes
681          case x: FilePermission if( x.getActions == "read" && (x.getName.contains(".class") || x.getName.endsWith(".jar")  || x.getName.endsWith(".so") ) ) => // ok
682          // configuration files
683          case x: FilePermission if( x.getActions == "read" && (x.getName.endsWith(".cfg") || x.getName.endsWith(".properties") ) )  => // ok
684          // cert files and config
685   ....

So it is the check itself which cause a check :/

So, more information: the problem is due to security check that are initiated during other security checks. Typically, trying to execute:

             ....
681          case x: FilePermission if( x.getActions == "read" && (x.getName.contains(".class") || x.getName.endsWith(".jar")  || x.getName.endsWith(".so") ) ) => // ok

needs to load FilePermission class file, abd that need to resolve URL (more permission), and then load a file from fs (more perm).
It seems that something changed in later JVM 1.8 JDK releases about what classes are loaded when. And that results in infinite loops due to impossibility to linearize the graphe of dependance check.

I thought about two resolutions, a correct one and a hacky one. Unfortunatly, I'm not able to implement the correct one for now, and I'm not sure I want to amass the quantity of java priviledges & security to be able to do it.
So, the correct solution is to be able to make the check permission implementation logic not subject to the permission check. This would be correct because the code for the check is statically knows and immutable, so we can assess its security. But I don't know of a way to escape the current security contexte (and it seems logical, since it's kind of the goal of the security context...)
S, the hacky one is to preload relevant classes out of the security context so that we don't have to do the resolution check later on. Of course, this is extremelly fragile.