Processor Security

EDQ, now allows optional use of security controls which can be used to increase the security level of EDQ processors, for example to block insecure uses of the Script processor. For backward compatibility reasons processor security is off by default, but it can be enabled by adding the following line to [EDQ Local Home]/director.properties:

processor.security= off/low/medium/high 

The processor security option acts in conjunction with the use of a Java Security Manager. The use of a Java Security Manager is controlled by a Java option specified on the server (-Djava.security.manager); this is enabled by default for new installations of EDQ on WebLogic server as it is specified in the setStartupEnv.sh script that sets the Java options for the EDQ server startup group. In other installations it must be manually specified.

The security level of each of the different processor.security settings is summarized below:

  • Off:

    No security restrictions are applied.

  • Low

    The following restrictions are applied:

    • The use of the Script processor from the tool palette, for direct use in processes, is disabled if the system is not running with a Java Security Manager.

    • If the system is running with a Java Security Manager, the Script processor is available but is only granted a very small set of default permissions, limited to data processing. Scripts will not be able to make network connections or issue commands outside of the application.

    Note:

    Java processors and scripts that are packaged in jars will run without any restrictions; if a jar contains a permissions element the processor will be granted only those permissions.

  • Medium:

    The same restrictions as Low apply, except that Java processors and scripts that are packaged in jars will be granted a very limited set of permissions. Any additional permissions required by the processor must be listed in permissions elements.

    To clarify the difference, in 'low' level, all permissions are granted and permissions elements restrict permissions; in 'medium' level, permissions are limited and permissions elements extend permissions. In both levels a processor with a permissions element will run with exactly the same set of permissions.

  • High:

    The same restrictions as 'medium' apply, except that only processors that are signed by the Oracle EDQ certificate, or by certificates granted to approved partners, will be allowed to include permissions elements that grant additional permissions to processors.

    If a permissions element is found in an unsigned jar the processors in the jar will be rejected and will not appear in the processor palette.

Default Permissions

When running with processor security set to medium or high, the permissions granted to processors allow the reading of these system properties:

  • java.version

  • java.vendor

  • java.vendor.url

  • java.class.version

  • os.name

  • os.version

  • os.arch

  • file.separator

  • path.separator

  • line.separator

  • java.specification.version

  • java.specification.vendor

  • java.specification.name

  • java.vm.specification.version

  • java.vm.specification.vendor

  • java.vm.specification.name

  • java.vm.version

  • java.vm.vendor

  • java.vm.name

No other permissions will be granted.

Giving Scripts More Permissions

An installation may wish to run with secure scripts but still allow users to perform some additional operations in ad-hoc scripts. A typical example will be to make web service calls. To allow this additional functionality, the system supports a configuration file listing additional permissions for ad-hoc scripts.

Additional permissions files are located in the security/permissions folder in the local configuration directory. For script processors, the file is named scriptprocessor.xml and for script match gadgets the file is named scriptgadget.xml. The file XML format is:

<permissions>
  <permission type="permissionclass" [name="targetname" [action="action"]]/>
  …
</permissions>

The permission class is the full name of any Java permissions class. The name attribute is present if the permission has a target name - the class has a two- or three-argument constructor. The action is present if the permission has an action - the class has a three-argument constructor.

For example, to grant the permission to read the file /etc/hosts:

<permission type="java.io.FilePermssion" name="file:/etc/hosts" action="read"/>

System properties can be included in the name using ${…} substitution. Alongside the standard system properties, these additional properties are available:

  • rootdir: The location of the web application root.

  • webinfdir: The location of the web application WEB-INF directory.

  • config.path: The configuration directory path. A permissions entry using ${config.path} in its name will be replaced by an entry for each location in the path.