Protecting Jenkins from its own pipelines and jobs

[Jason Hull]

Hi!

How do I protect Jenkins from its own jobs and pipelines?

For instance, I can create a freestyle job with a script step that does something like:

echo 'my own key' >> /home/jenkins/.ssh/authorized_keys

Also, I can write a pipeline like:

stage 'Destroy'
'rm -rf /home/jenkins'.execute
echo 'Bye!'

How to I prevent these types of malicious activities?

Thanks!!

Jason

[Victor Martinez]

I see there are two different points:

1) Securing your Jenkins instance

a)  Probably you could add some security policies:

   - https://wiki.jenkins-ci.org/display/JENKINS/Securing+Jenkins

   - https://wiki.jenkins-ci.org/display/JENKINS/Ownership-Based+security

b) Avoid granting privileges to the 'jenkins' user more than the required

c) Also you could develop a particular plugin to avoid running jobs which contains those particular rm -rf, although some evil might skip that and do something else...

2) Configuration Management tools

Regarding your authorized keys, if you use any kind of Configuration Management tools you might fix that easily as those systems won't be in the expected state and will be changed immediately or after a period of time.

Although I'll prefer to trust my users rather than stopping them/blocking them. But that's my point of view.

Cheers

[Jason Hull]

Thank you for your response, Victor!

Below are my responses to your comments. Before that, however, for background I should state that I work in a large enterprise in a highly regulated industry. Thus my keen interest in security.

On Wednesday, March 30, 2016 at 3:31:18 PM UTC-5, Victor Martinez wrote:

I see there are two different points:

1) Securing your Jenkins instance

a)  Probably you could add some security policies:

   - https://wiki.jenkins-ci.org/display/JENKINS/Securing+Jenkins

   - https://wiki.jenkins-ci.org/display/JENKINS/Ownership-Based+security

Thank you for the links. There's a lot of info here so I'm still digesting, but I think these are (mostly) user security oriented and don't necessarily discuss self-inflicted wounds.

 

b) Avoid granting privileges to the 'jenkins' user more than the required

This is the crux of the problem. Jobs run as Jenkins and thus can edit anything that Jenkins owns, like authorized_keys, credentials.xml, etc.

 

c) Also you could develop a particular plugin to avoid running jobs which contains those particular rm -rf, although some evil might skip that and do something else...

The links you shared in a) lead me to https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+Master+Access+Control.

My gut tells me blacklisting will be too limited/ineffective and whitelisting will be too crippling.

2) Configuration Management tools

Regarding your authorized keys, if you use any kind of Configuration Management tools you might fix that easily as those systems won't be in the expected state and will be changed immediately or after a period of time.

Yes, this is a good point. However I'd like to lock the door rather than just closing it automatically after an intruder has walked in. 

Although I'll prefer to trust my users rather than stopping them/blocking them. But that's my point of view.

I agree with you. This doesn't cut it, however, in highly secure/regulated environments.

[Vincent Latombe]

My two cents :

* Set executors number on master to 0 and run jobs only on slaves. That prevents anyone without admin access to your master to screw it.

* If you're still afraid to screw your slaves, use one-off slaves using one of the Cloud implementations (using VMWare, Docker, or any other solution which would be applicable in your case)

* Restrict who can define jobs either directly in Jenkins, or by using a plugin such as Job DSL plugin which allows you to put these definition in a SCM (then you use whatever access control your SCM allows to review any incoming changes)

Vincent

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/771ee4fe-5ed7-4d22-9891-f6c73777a426%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Wednesday, March 30, 2016 at 3:33:50 PM UTC-4, Jason Hull wrote:

For instance, I can create a freestyle job with a script step that does something like:

echo 'my own key' >> /home/jenkins/.ssh/authorized_keys

If you have any executors configured on your master, your system is insecure. Set it to zero and use agents exclusively.

I can write a pipeline like:

stage 'Destroy'
'rm -rf /home/jenkins'.execute
echo 'Bye!'

Will be rejected when the Groovy sandbox option is selected. (If unselected, the script would go into an administrative queue, where you would reject it and presumably punish the offender.) 

[Daniel Beck]

On 04.04.2016, at 19:19, Jesse Glick <jgl...@cloudbees.com> wrote:

> If you have any executors configured on your master, your system is insecure. Set it to zero and use agents exclusively.

Also mentioned on https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices as the second item after setting up security.