Script Security1.29.1Minimum Jenkins requirement: 1.625.3ID: script-security
(adapted from information on template security in CloudBees Jenkins Enterprise)
Various Jenkins plugins require that users define custom scripts, most commonly in the Groovy language, to customize Jenkins’s behavior. If everyone who writes these scripts is a Jenkins administrator—specifically if they have the Overall/RunScripts permission, used for example by the Script Console link—then they can write whatever scripts they like. These scripts may directly refer to internal Jenkins objects using the same API offered to plugins. Such users must be completely trusted, as they can do anything to Jenkins (even changing its security settings or running shell commands on the server).
However, if some script authors are “regular users” with only more limited permissions, such as Job/Configure, it is inappropriate to let them run arbitrary scripts. To support such a division of roles, the Script Security library plugin can be integrated into various feature plugins. It supports two related systems: script approval, and Groovy sandboxing.
The first, and simpler, security system is to allow any kind of script to be run, but only with an administrator’s approval. There is a globally maintained list of approved scripts which are judged to not perform any malicious actions.
When an administrator saves some kind of configuration (for example, a job), any scripts it contains are automatically added to the approved list. They are ready to run with no further intervention. (“Saving” usually means from the web UI, but could also mean uploading a new XML configuration via REST or CLI.)
When a non-administrator saves a template configuration, a check is done whether any contained scripts have been edited from an approved text. (More precisely, whether the requested content has ever been approved before.) If it has not been approved, a request for approval of this script is added to a queue. (A warning is also displayed in the configuration screen UI when the current text of a script is not currently approved.)
An administrator may now go to Manage Jenkins » In-process Script Approval where a list of scripts pending approval will be shown. Assuming nothing dangerous-looking is being requested, just click Approve to let the script be run henceforth.
If you try to run an unapproved script, it will simply fail, typically with a message explaining that it is pending approval. You may retry once the script has been approved. The details of this behavior may vary according to the feature plugin integrating this library.
Waiting for an administrator to approve every change to a script, no matter how seemingly trivial, could be unacceptable in a team spread across timezones or during tight deadlines. As an alternative option, the Script Security system lets Groovy scripts be run without approval so long as they limit themselves to operations considered inherently safe. This limited execution environment is called a sandbox. (Currently no sandbox implementations are available for other languages, so all such scripts must be approved if configured by non-administrators.)
To switch to this mode, simply check the box Use Groovy Sandbox below the Groovy script’s entry field. Sandboxed scripts can be run immediately by anyone. (Even administrators, though the script is subject to the same restrictions regardless of who wrote it.) When the script is run, every method call, object construction, and field access is checked against a whitelist of approved operations. If an unapproved operation is attempted, the script is killed and the corresponding Jenkins feature cannot be used yet.
The Script Security plugin ships with a small default whitelist, and integrating plugins may add operations to that list (typically methods specific to that plugin).
But you are not limited to the default whitelist: every time a script fails before running an operation that is not yet whitelisted, that operation is automatically added to another approval queue. An administrator can go to the same page described above for approval of entire scripts, and see a list of pending operation approvals. If Approve is clicked next to the signature of an operation, it is immediately added to the whitelist and available for sandboxed scripts.
Most signatures be of the form
method class.Name methodName arg1Type arg2Type…, indicating a Java method call with a specific “receiver” class (
this), method name, and list of argument (or parameter) types. (The most general signature of an attempted method call will be offered for approval, even when the actual object it was to be called on was of a more specific type overriding that method.) You may also see
staticMethod for static (class) methods,
new for constructors, and
field for field accesses (get or set).
Administrators in security-sensitive environments should carefully consider which operations to whitelist. Operations which change state of persisted objects (such as Jenkins jobs) should generally be denied. Most
getSomething methods are harmless.
Be aware however that even some “getter” methods are designed to check specific permissions (using an ACL: access control list), whereas scripts are often run by a system pseudo-user to whom all permissions are granted. So for example
method hudson.model.AbstractItem getParent (which obtains the folder or Jenkins root containing a job) is in and of itself harmless, but the possible follow-up call
method hudson.model.ItemGroup getItems (which lists jobs by name within a folder) checks Job/Read. This second call would be dangerous to whitelist unconditionally, since it would mean that a user who is granted Job/Create in a folder would be able to read at least some information from any jobs in that folder, even those which are supposed to be hidden according to a project-based authorization strategy; it would suffice to create a job in the folder which includes a Groovy script like this (details would vary according to the integrating plugin):
When run, the script output would display at least the names of supposedly secret projects. An administrator may instead click Approve assuming permission check for
getItems; this will permit the call when run as an actual user (if the integrating plugin ever does so), while forbidding it when run as the system user (which is more typical). In this case,
getItems is actually implemented to return only those jobs which the current user has access to, so if run in the former case (as a specific user), the description will show just those jobs they could see anyway. This more advanced button is shown only for method calls (and constructors), and should be used only where you know that Jenkins is doing a permission check.
The easy way
For a typical Groovy integration, in which you offer the user the option of using either script approval or the sandbox, change your describable’s
String-valued script field into a
SecureGroovyScript field. In your constructor, before storing the value, call
configuringWithKeyItem (if there could only be one such script per top-level item) or
configuringWithNonKeyItem (if there might be several). The configuration form should use
<f:property field="…"/> to pick up the script and sandbox configuration. When you want to run the script, just call
(For compatibility with old data, pick a different field name and deprecate the original. Then you can define a
readResolve method which sets the new field to a
SecureGroovyScript with the sandbox off, calls
configuring(ApprovalContext.create()) on it to notify the system that an unapproved script has been loaded, and unsets the old field.)
The hard way
To be used if you need more control than
boolean sandbox field into your configuration.
When unset, you need to call
ScriptApproval.configuring in the
ApprovalContext.withCurrentUser, and also
withItemAsKey where applicable (when there is just one script per job); otherwise at least
withItem where applicable, and/or
withKey when you can uniquely identify this usage from the context (
StaplerRequest.findAncestorObject is helpful here). This lets the system know a (possibly) new script has been configured by a particular person. You will also need a
readResolve that calls
configuring to notify the system when a configurable with script has been loaded from disk (and thus the configurer is unknown). Call
ScriptApproval.using when the script is run, and catch
UnapprovedUsageException if necessary. The descriptor should use form validation on the script field and call
ScriptApproval.checking (generally your descriptor should already be doing at least a syntax check on this field).
When the sandbox field is set, you need merely set up the Groovy shell with
GroovySandbox.createSecureCompilerConfiguration and then call
GroovySandbox.run; be prepared to catch
RejectedAccessException and call
Preapproved methods for the sandbox
To preapprove some particular method calls, simply annotate them with
@Whitelisted if in your plugin; otherwise you can register (with
ProxyWhitelist delegating to
StaticWhitelist.from and loading a text file listing whitelisted methods.
Classpath for evaluating scripts
When constructing a
GroovyShell to evaluate a script, or calling
SecureGroovyScript.evaluate, you must pass a
ClassLoader which represents the effective classpath for the script. You could use the loader of Jenkins core, or your plugin, or
Whatever you choose, do not allow an unprivileged user to add arbitrary classpath entries by making a
URLClassLoader! This would make it trivial to bypass all security when using the sandbox. (A user need merely make this or another job archive a JAR containing some class with a static method marked
@Whitelisted and doing whatever they like, then call the method from their script.) No attack has yet been demonstrated when using whole-script approval--a
URLClassLoader with normal parent-first delegation would not permit trivial masking of innocent-looking APIs by compromised versions--but it is likely that some clever use of
META-INF/services/org.codehaus.groovy.transform.ASTTransformation or similar could cause an otherwise safe script to behave in an unexpected and unauthorized manner. JENKINS-22834 suggests a safe standard alternative.
When writing tests for plug-ins that use the Script Security Plugin you may encounter some errors in your tests.
- If your tests call, direct or indirectly, the
ScriptApproval.get()method, then your unit tests must use
Jenkins.getInstance()does not return
- It is likely that tests that were working now start to fail if you are not using the sandbox. It occurs because they are being enqueued for approval. In case you need to execute scripts regardless of approvals,
ScriptApproval.get().preapprove(script, GroovyLanguage.get())will ensure that all configured scripts are approved.
- Alternately, you can have your tests run scripts using the sandbox. In this case you may need to whitelist methods used by your tests---either generally for real users, or using a
@TestExtensionto have a whitelist just for tests.
Version 1.29.1 (July 10, 2017)
Version 1.29 (Jun 15, 2017)
- Whitelist additions, particularly for
Version 1.28 (Jun 05, 2017)
JENKINS-34741 Unclassified error when using Groovy struct constructors.
Default whitelist additions.
Version 1.27 (Feb 27, 2017)
- JENKINS-41797 Race condition could corrupt internal whitelist metadata.
- JENKINS-39159 File handle leak when using custom script classpath could lead to unwanted locks on Windows or NFS.
- Default whitelist additions.
Version 1.26 (Feb 13, 2017)
- Default whitelist additions.
Version 1.25 (Jan 03, 2017)
- More whitelist and blacklist entries.
- Display a warning about previously approved signatures which are now in the blacklist.
Version 1.24 (Oct 20, 2016)
- JENKINS-38908 Improper handling of some varargs methods.
- Various whitelist additions.
Version 1.23 (Sep 21, 2016)
- Better report JENKINS-37599, a bug in core tickled by the Promoted Builds Plugin.
- A few new whitelist and blacklist entries.
Version 1.22 (Aug 15, 2016)
- Introduce a class loader caching layer for the Groovy sandbox to work around core performance limitations such as JENKINS-23784.
- JENKINS-37344 Default whitelist additions pertaining to collections.
Version 1.21 (Jul 11, 2016)
- Default whitelist additions pertaining to build changelogs (JENKINS-30412).
Version 1.20 (Jun 20, 2016)
- Various default whitelist additions.
- JENKINS-34739 Support for varargs methods.
Version 1.19 (Apr 26, 2016)
- JENKINS-24399 Prohibit class directories from being approved classpath entries.
- JENKINS-33023 Support
- Permit metaclass methods to be run.
- Some miscellaneous whitelist and blacklist additions.
Version 1.18.1 (Apr 11, 2016)
- Security release (CVE-2016-3102). advisory
Version 1.18 (Apr 04, 2016)
- Groovy prefers a getter/setter to a field access, so act accordingly, particularly when suggesting signatures to approve.
- JENKINS-27725 Various fixes to handling of GDK methods.
- Some miscellaneous whitelist and blacklist additions.
- JENKINS-26481 Supporting fix to GDK method handling necessary to support calls such as
Version 1.17 (Jan 25, 2016)
boolean TheClass.isProp(), not just
Version 1.16 (Jan 19, 2016)
- Many more default whitelist entries, including standard Groovy operators and GDK methods.
- JENKINS-30432 Warn about dangerous signatures.
- JENKINS-31234 Groovy allows
Singleton.instanceas an alias for
- JENKINS-31701 Misclassification of a method taking
longand being passed an
Version 1.15 (Aug 20, 2015)
- Added a number of new default whitelist entries.
- Properly classify pseudofields of a
- JENKINS-29541 Methods on a
GStringmay really be called on a
- Corrected classification of methods ambiguous between
- JENKINS-28586 Corrected handling of receivers inside a
- JENKINS-28154 Fixing handling of Groovy operators.
Version 1.14 (Apr 22, 2015)
- Better error message when you mistype a method name on a Groovy class.
- Default to using sandbox mode when the current user is not an administrator.
Version 1.13 (Feb 02, 2015)
- Testability fix only.
Version 1.12 (Dec 04, 2014)
- JENKINS-25914 Support for special whitelist of
envin Workflow plugins.
Version 1.11 (Dec 03, 2014)
- Handling some more Groovy constructs, such as the
=~operator, and GDK methods like
Version 1.10 (Nov 14, 2014)
- JENKINS-25524 Handle ambiguous method overloads better.
Version 1.9 (Nov 4, 2014)
- Code can escape sandbox if there are multiple copies of
groovy-sandbox.jarin Jenkins (JENKINS-25348)
Version 1.8 (Oct 29, 2014)
groovy-sandbox1.8 has a few fixes.
Version 1.7 (Oct 13, 2014)
- JENKINS-25118 Handle methods with primitive arguments.
Version 1.6 (Oct 2, 2014)
GroovyObject.invokeMethod(String,Object)correctly during call site selecction.
Version 1.5 (Aug 19, 2014)
- JENKINS-22834 Added support for custom classpaths.
Version 1.4 (Jun 08, 2014)
- Do not bother enforcing whole-script approval when Jenkins is unsecured anyway.
- Some changes to make writing acceptance tests easier.
Version 1.3 (May 13, 2014)
- Fixing some regressions from 1.2.
Version 1.2 (May 13, 2014)
- Updated Groovy sandbox library for better language coverage.
Version 1.1 (May 06, 2014)
- Making it possible to use Groovy functions with
GroovySandbox.runto stop whitelists from being consulted on methods defined in the script itself.
Version 1.0 (Apr 15, 2014)
- String concatenation fix in sandbox.
- Preapprove the empty script.
- Support for static fields in sandbox.
- Changed package of
Version 1.0 beta 6 (Mar 31, 2014)
Version 1.0 beta 5 (Mar 13, 2014)
- Fixed various bugs in the Groovy sandbox.
Version 1.0 beta 4 (Mar 12, 2014)
Version 1.0 beta 3 (Mar 01, 2014)
- Reverted GString fix for now
Version 1.0 beta 2 (Feb 28, 2014)
- initialization bug fix
- Groovy GString fix
Version 1.0 beta 1 (Feb 28, 2014)
- Initial version.