Skip to main content
Version: Release Next

Configure Script Security

This guide is for administrators who control how scripts are created and executed in Digital.ai Release. It covers the Create and edit scripts permission, script sandboxing, Java class access restrictions, and static script validation.

Release 26.3 supports JDK 21 and JDK 25. The script security mechanisms available to Release differ by JDK version. JDK 21 deployments can continue to use the Java Security Manager and the script.policy file to sandbox script execution. JDK 25 no longer supports the Java Security Manager, so Release provides script security controls for JDK 25 that do not depend on it. For instructions on switching JDK versions, see Configure the JDK Version for Release.

For JDK 25 deployments, use the controls in this guide to:

  • Restrict who can create and modify scripts.
  • Restrict access to Java classes at runtime.
  • Validate Jython scripts for restricted modules, functions, attributes, and syntax before execution.
caution

Applying the recommended JDK 25 security configuration can prevent scripts that ran in earlier Release versions from running. Before you use JDK 25 in production, apply the recommended configuration and test releases and templates that use scripts in a non-production environment. For more information, see Upgrade Impact.

Restrict Who Can Create and Edit Scripts​

The global permission Create and edit scripts controls who can create or modify scripts and script-based configuration. It applies to:

  • Jython Script, Groovy Script, and External Script tasks, including the Script URL of External Script tasks
  • Preconditions of type Jython
  • Failure handler scripts
  • Webhook trigger filters that use Jython expressions
  • Scripted authentication (Jython) for webhook HTTP endpoints

By default, all authenticated users have this permission. When one or more roles are assigned to the permission, only users in those roles can create or edit scripts. To assign roles, go to Settings > Users and permissions > Permissions. For more information, see Global Permissions.

The permission works in conjunction with existing permissions. To modify a script, a user must have the Create and edit scripts permission in addition to any existing checks that apply to the resource, such as the task access settings for script task types and the folder-level Edit scripts, Edit preconditions, and Edit failure handlers permissions described in Folder Teams and Permissions.

The permission only governs creating and modifying scripts. Users without it can still view releases and templates, start releases, and execute tasks, including tasks that contain existing scripts. The restriction is enforced both in the user interface and in the REST API.

note

This permission is particularly important for JDK 25 deployments, where the Java Security Manager is not available.

Apply configuration changes​

The sandbox, Java class access, and static validation settings are stored in the xl-release.conf configuration file. How you edit the file and restart the server depends on your installation type.

  • JVM-based (installer) installations: Edit XL_RELEASE_SERVER_HOME/conf/xl-release.conf on the server, then restart the Release server for the change to take effect.
  • Operator-based (Kubernetes) installations: Apply the settings through the custom resource (CR) by patching the xl-release.conf template, as described in Customize Your Site - Release Custom Configuration. The operator restarts the Release pods automatically.

The Script Sandbox​

When a script task becomes active, Release executes the script in a sandbox on the Release server. The sandbox restricts access to the file system, the network, and Java classes that are not part of the Release API.

The sandbox is enabled by default. Disabling it is not recommended. To disable it, set the following property in the XL_RELEASE_SERVER_HOME/conf/xl-release.conf file:

xl.security.scripting.sandbox.enabled = false

The sandbox applies to both JDK 21 and JDK 25, but it controls different aspects of each deployment.

JDK 21​

When the sandbox is enabled, restricted scripts use the Security Manager permissions defined by the built-in grants and the script.policy file, and configured Jython validation is applied. When the sandbox is disabled, Security Manager policy enforcement, restricted script-engine selection, and Jython validation are bypassed.

JDK 25​

When the sandbox is enabled, Release enforces Java class access restrictions directly and applies Jython validation. When the sandbox is disabled, Java class access restrictions and Jython validation are bypassed.

caution

Disabling the sandbox removes script security controls that are particularly important on JDK 25, where the Java Security Manager is not available.

For how to apply this change, see Apply configuration changes.

Restrict Java Class Access​

On JDK 25, the sandbox validates every Java class that a Jython or Groovy script loads. On JDK 21, class access is controlled through the script.policy file instead. A built-in allowlist of safe classes is allowed by default. You can adjust class access on JDK 25 with two settings in the XL_RELEASE_SERVER_HOME/conf/xl-release.conf file:

  • xl.security.scripting.sandbox.allowedJavaClasses: Java classes or packages that scripts may load, in addition to the built-in allowlist.
  • xl.security.scripting.sandbox.deniedJavaClasses: Java classes or packages that scripts may never load. Use this setting to fine-tune the allowlist.

Entries can name a single class or a whole package. For example:

xl.security.scripting.sandbox {
  allowedJavaClasses = ["accessClass.com.company.domain.*", "accessClass.com.company.utils.HelperClass"]
  deniedJavaClasses = ["accessClass.com.company.utils.LegacyHelperClass"]
}

Access decisions follow this precedence:

  1. Classes listed in deniedJavaClasses are always rejected.
  2. Classes that are not in the built-in allowlist or in allowedJavaClasses are rejected.
  3. All other classes are allowed.

The default denylist includes high-risk Java APIs such as java.lang.System, java.lang.Runtime, java.io.File, the java.nio.file package, and raw networking classes. Attempts to load a denied class are rejected during class loading and logged for auditing.

In earlier versions, class access was granted through RuntimePermission "accessClass.*" entries in the XL_RELEASE_SERVER_HOME/conf/script.policy file. When you upgrade, move those entries to allowedJavaClasses.

For how to apply this change, see Apply configuration changes.

Static Script Validation​

Release validates Jython scripts before executing them. A script that contains restricted syntax fails validation and does not run. This validation applies on both JDK 21 and JDK 25.

With the recommended JDK 25 restrictions configured, validation rejects:

  • from x import y import statements. Import modules with import x instead.
  • Restricted modules, such as os, subprocess, imp, importlib, thread, and threading, and restricted Java module imports.
  • Restricted functions, such as __import__, eval, exec, and getattr.
  • Restricted attributes, such as __class__, class, and getClass, and other reflection-oriented attributes.
  • Restricted built-ins, such as open, file, execfile, reload, and input, which are not available in scripts.

Validation covers nested code blocks, so restricted syntax inside functions, loops, and conditionals is also rejected.

Configure the restricted modules, functions, and attributes with the following settings in the XL_RELEASE_SERVER_HOME/conf/xl-release.conf file:

xl.security.scripting.sandbox.jython.restricted-modules = ["importlib", "imp", "tempfile", "linecache", "shutil", "os", "os.path",
    "getpass", "platform", "threading", "thread", "subprocess", "webbrowser", "cmd", "pdb", "bdb", "gc", "user", "code", "codeop",
    "zipimport", "pkgutil", "modulefinder", "runpy", "distutils", "compiler", "posix", "pwd", "grp", "posixfile", "commands",
    "socket", "select", "signal", "marshal", "pickle", "cPickle", "ctypes", "mmap", "fcntl", "__builtin__", "__builtins__", "builtins"]

xl.security.scripting.sandbox.jython.restricted-functions = ["__import__", "eval", "exec", "getattr", "compile", "reload", "input",
    "execfile", "open", "file"]

xl.security.scripting.sandbox.jython.restricted-attributes = ["class", "getClass", "__class__", "__bases__", "__subclasses__",
    "__mro__", "__globals__", "__code__", "func_globals", "func_code", "__dict__", "__getattribute__", "__reduce__", "__reduce_ex__", "getenv"]

To allow a restricted module, remove it from the xl.security.scripting.sandbox.jython.restricted-modules list. For the default list, see Create a Jython Script task.

caution

Restricting __import__ can cause existing scripts to fail. Test existing scripts after applying these settings. For other compatibility considerations, see Upgrade Impact.

For how to apply this change, see Apply configuration changes.

Runtime Hardening​

On JDK 25, the Jython interpreter that runs scripts is hardened before any user-authored script executes:

  • Denied import attempts are logged with their execution context.
  • The restricted execution context is cleared after each script execution.

Release helper modules and API objects that scripts normally use continue to function in the restricted interpreter.

Upgrade Impact​

Scripts that ran in earlier Release versions may be blocked after upgrading to Release 26.3, regardless of the JDK version:

  • Scripts that use from x import y imports fail static validation.
  • Scripts that use newly restricted modules, functions, attributes, or built-ins fail static validation.
  • On JDK 25, scripts that load Java classes outside the built-in allowlist are rejected at class loading, unless the classes are added to allowedJavaClasses.
  • On JDK 25, custom script.policy files are no longer used. Move custom accessClass entries to the allowedJavaClasses setting.

Test all releases and templates that contain script tasks, Jython preconditions, script failure handlers, or webhook scripts in a non-production environment before upgrading production.