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

Option to disable sandbox in CpsScmFlowDefinition

    Details

    • Similar Issues:

      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

            Activity

            Hide
            progovoy Pavel Rogovoy added a comment -

            +1 for adding a feature to turn off the script security altogether. I spend a lot of time fighting with this even though everyone is admin on the team. "Permisssive Script Security" plugin is not the best solution as it doesn't work for us! I think this feature must be disabled altogether as it performs very awful as for today.

            Show
            progovoy Pavel Rogovoy added a comment - +1 for adding a feature to turn off the script security altogether. I spend a lot of time fighting with this even though everyone is admin on the team. "Permisssive Script Security" plugin is not the best solution as it doesn't work for us! I think this feature must be disabled altogether as it performs very awful as for today.
            Hide
            jonasatwork 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.

            Show
            jonasatwork 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.
            Hide
            jglick Jesse Glick added a comment -

            Better to use trusted libraries.

            Show
            jglick Jesse Glick added a comment - Better to use trusted libraries.
            Hide
            mvr 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?

            Show
            mvr 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?
            Hide
            chenrici Christoph Henrici added a comment -

            Second   matt matthews

            Show
            chenrici Christoph Henrici added a comment - Second   matt matthews

              People

              • Assignee:
                Unassigned
                Reporter:
                jglick Jesse Glick
              • Votes:
                101 Vote for this issue
                Watchers:
                104 Start watching this issue

                Dates

                • Created:
                  Updated: