Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-28178

Option to disable sandbox in CpsScmFlowDefinition

      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.

          [JENKINS-28178] Option to disable sandbox in CpsScmFlowDefinition

          Jonas Jonsson added a comment -

          As a Jenkins-admin with quite a few system groovy scripts, I would like to white-list certain paths (that contains my version controlled scripts) as 100% secure, so that I (once the change has been submitted) can use the latest and most up-to-date version of my script immediately. 

          May it be pipelines or groovy system scripts, if the Jenkins-admin approve the scripts (before they're executed), they should be allowed to run.

          Jonas Jonsson added a comment - As a Jenkins-admin with quite a few system groovy scripts, I would like to white-list certain paths (that contains my version controlled scripts) as 100% secure, so that I (once the change has been submitted) can use the latest and most up-to-date version of my script immediately.  May it be pipelines or groovy system scripts, if the Jenkins-admin approve the scripts (before they're executed), they should be allowed to run.

          Jesse Glick added a comment -

          Better to use trusted libraries.

          Jesse Glick added a comment - Better to use trusted libraries.

          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?

          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?

          Second   mvr

          Christoph Henrici added a comment - Second   mvr

          Third that.

          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

          +1

          once added a comment -

          Same here

          once added a comment - Same here

          Jani R. added a comment -

          +1

          Jani R. added a comment - +1

          James Baxter added a comment -

          +1

          James Baxter added a comment - +1

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            121 Vote for this issue
            Watchers:
            117 Start watching this issue

              Created:
              Updated: