Details
-
New Feature
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
Description
Currently CpsScmFlowDefinition enforces sandbox mode on the grounds that whole-script approval is unrealistic (an administrator would need to approve every SCM revision, and Jenkins cannot automatically approve revisions like it could from GUI changes to a CpsFlowDefinition by an administrator).
There should however be an option to simply trust the script as it comes from the SCM. This could be checked by default if Jenkins were unsecured; for a secured Jenkins, the default should remain to use the sandbox, though you could switch to trusted mode with a stern warning in form validation explaining that you are responsible for auditing all changes to that SCM repository, and noting that attackers with SCM access could take over control of Jenkins in ways that might make auditing difficult. (For example, someone with push access to a Git repository could push a script which obtains the API token of a legitimate Jenkins administrator, mails it to the attacker, then deletes the current build record; and finally force-push the attacking script out of existence except via the reflog.)
Pending such an option, the workaround is given by the tutorial here: define a CpsFlowDefinition with an approved script that checks out the SCM and uses load to run it. This has the same effect at the price of more awkward configuration.
Attachments
Issue Links
- is related to
-
JENKINS-25784 Select sandbox mode by default if current user lacks RUN_SCRIPTS
-
- Resolved
-
Activity
Suggesting to just use shared/trusted libraries is not enough IMHO, we need a switch to turn this stuff off. as an example, today I have a basic Jenkinsfile that's throwing errors with [].tail():
Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods tail java.lang.Object[].
Job console offers a link to go to the ScriptApproval URL to approve, but then it does not remember the approval.. I return to the job generating the error and then it happens again in exactly the same way, telling me to approve. There's nothing further I can even do here to debug that problem (which is just another distraction from the work I really want to do), so I get forced into rewrite `[].tail()` as different-but-equivalent groovy, something with `[].findAll{}`, which just works.
So why is Jenkins not remembering the approvals? Why is `findAll` safer than `tail`? Why does this plugin exist in the ecosystem if it doesn't work and can't work? https://wiki.jenkins.io/display/JENKINS/Permissive+Script+Security+Plugin
Like other users, our Jenkins is behind a VPN, and we have multiple Jenkins instances so that we don't have to deal with all the complexity of highly granular user/job/credential permissioning. Since all people who can login to a given instance are admins on that instance.. our experience is that none of script-security stuff adds security, it just degrades our stability.
Please, can we just get a config option to just turn this off everywhere?
matt matthews
added a comment - - edited Suggesting to just use shared/trusted libraries is not enough IMHO, we need a switch to turn this stuff off. as an example, today I have a basic Jenkinsfile that's throwing errors with [].tail():
Scripts not permitted to use staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods tail java.lang.Object[].
Job console offers a link to go to the ScriptApproval URL to approve, but then it does not remember the approval.. I return to the job generating the error and then it happens again in exactly the same way, telling me to approve. There's nothing further I can even do here to debug that problem (which is just another distraction from the work I really want to do), so I get forced into rewrite `[].tail()` as different-but-equivalent groovy, something with `[].findAll{}`, which just works.
So why is Jenkins not remembering the approvals? Why is `findAll` safer than `tail`? Why does this plugin exist in the ecosystem if it doesn't work and can't work? https://wiki.jenkins.io/display/JENKINS/Permissive+Script+Security+Plugin
Like other users, our Jenkins is behind a VPN, and we have multiple Jenkins instances so that we don't have to deal with all the complexity of highly granular user/job/credential permissioning. Since all people who can login to a given instance are admins on that instance.. our experience is that none of script-security stuff adds security, it just degrades our stability.
Please, can we just get a config option to just turn this off everywhere? 
Fernando Nasser
added a comment - Third that. 
Dmitry Vilkov
added a comment - +1 mvr
I've created jenkins.io account just to make this comment... You can imagine the pain 
Dmitry Vilkov
added a comment - +1 mvr
I've created jenkins.io account just to make this comment... You can imagine the pain
Better to use trusted libraries.