-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Groovy plugin 2.0, Jenkins 2.42.1
Prior to the 2.0 upgrade, we had a set of system groovy script steps in jobs to do maintenance on the server (walk machines and clean tmp folders, etc.)
After 2.0, because everything is run under the sandbox, to run these scenarios, I need to whitelist a bunch of methods. However, a lot of these methods aren't ones I would like to whitelist (hudson.getInstance, etc.) because then other cases like job DSL could use them maliciously.
Is there a way I can set up the system groovy step to not do method checks for specific jobs?
[JENKINS-43700] No way to configure System Groovy Script step to not use sandbox
Matthew Mitchell
created issue -
Chris Weaver
made changes -
| Issue Type | Original: Improvement [ 4 ] | New: Bug [ 1 ] |
Chris Weaver
added a comment - Use of Execute System Groovy Script is supposed to bypass the Groovy sandbox. This change broke a number of our scripts as well. Having to whitelist a bunch of signatures defeats the purpose. This is a bug....
Chris Weaver
added a comment - Use of Execute System Groovy Script is supposed to bypass the Groovy sandbox. This change broke a number of our scripts as well. Having to whitelist a bunch of signatures defeats the purpose. This is a bug.... 
Matthew Mitchell
added a comment - I think this is new functionality since 2.0 and appears to be intentional:
From https://jenkins.io/security/advisory/2017-04-10/#groovy-plugin
"One of the Groovy Plugin’s major features is the ability to run "System Groovy". This allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
While the plugin previously did not allow users to interactively configure System Groovy build steps unless they had the Overall/Run Scripts permission, this could be circumvented by using the Remote API or Jenkins CLI.
This has been addressed in Groovy Plugin version 2.0 by integrating with Script Security Plugin.
To find out whether you’re likely to be impacted by these changes, use these scripts."
Matthew Mitchell
added a comment - I think this is new functionality since 2.0 and appears to be intentional:
From https://jenkins.io/security/advisory/2017-04-10/#groovy-plugin
"One of the Groovy Plugin’s major features is the ability to run "System Groovy". This allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.
While the plugin previously did not allow users to interactively configure System Groovy build steps unless they had the Overall/Run Scripts permission, this could be circumvented by using the Remote API or Jenkins CLI.
This has been addressed in Groovy Plugin version 2.0 by integrating with Script Security Plugin .
To find out whether you’re likely to be impacted by these changes, use these scripts ." We had to downgrade back to 1.30 due to this; we have a massive system groovy script and it would take ages to keep running it over and over again to whitelist all of the calls (some of which really shouldn't really be whitelisted anyway). Wish we could just whitelist based on the hash of the entire script file or something.
Matthew Mitchell
added a comment - So if you use the newest plugin, but disable the sandbox. We then use the Authorize Project plugin to ensure jobs are run by default as non-admin. This will cause the plugin to still ask for approval when running the job on periodic/automatic triggers, but it will approve the entire script rather than individual signatures.
Matthew Mitchell
added a comment - So if you use the newest plugin, but disable the sandbox. We then use the Authorize Project plugin to ensure jobs are run by default as non-admin. This will cause the plugin to still ask for approval when running the job on periodic/automatic triggers, but it will approve the entire script rather than individual signatures. The script is being read from an hg repo in the workspace so the sandbox checkbox is not available in our case. (and I'd rather avoid using the inline script approach with a 1000 line script~)
Matthew Mitchell
added a comment - bonuslord We have the same issue but use job dsl to read the file from the repo at the current version and prep the inline script job.
Matthew Mitchell
added a comment - bonuslord We have the same issue but use job dsl to read the file from the repo at the current version and prep the inline script job. Ooo, interesting solution; hadn't actually heard of the Job DSL plugin but it looks pretty useful...
FYI this still appears to work if you configure an inline script and don't check the "use groovy sandbox" checkbox. This checkbox is not available when the groovy script is read from the workspace.