This page is created for discussion on 'security problems relating to job execution in Jenkins'.
As mentioned in Securing Jenkins#Security Implication, Jenkins security setup does NOT imply 'secure job execution'.
I'd like to summarize these issues on this page, and ask you for your opinion.
As you know, Jenkins already supports "Project-based Matrix Authorization Strategy" to isolate different users or teams.
In some case, it seems more useful and desirable to mix jobs of multiple teams into single Jenkins instance with the above strategy,
rather than running many small Jenkins instances by each team,
because running many Jenkins instances may often need a lot of administration labor and cost.
But as someone pointed out, even when "Project-based Matrix Authorization Strategy" is used,
there seems to exist some serious security problems relating to "job execution"
or treatment of credentials for systems outside Jenkins, such as OS account for slave nodes and Subversion account.
Summary of problems
As far as I can find out, there are 3 security problems below in current Jenkins.
1) A job can easily access files/folders beyond the workspace of the job.
As a result, a job can read, update or destroy workspace files/folders of other jobs or other resources,
if these resources are on the same slave machine or accessible from the same machine.
A job can also read/write Jenkins configuration files because jobs are executed with the same user id (e.g., tomcat6).
2) A job can easily use any slave node for execution, even when these slave nodes are exclusive to other jobs.
As a result, the case of 1) can be done easily.
3) When using Subversion plugin, a job can easily access to Subversion repositories/URLs,
even when these repositories/URLs are exclusive to other jobs.
(e.g. Sorry, this is in Japanese. http://groups.google.com/group/jenkinsci-ja/browse_thread/thread/f0b4b388a8c3688d/9db9f17a7edf1210?show_docid=9db9f17a7edf1210)
The case of 1) seems to be not a problem of Jenkins itself, rather a problem about configuration of slave nodes.
We must appropriately configure OS user and his privilege used by job execution.
Strict access control like 'chroot' may be needed in some cases.
The situation is quite same to when adding a new user account to the machine, especially a user account for remote execution.
For that purpose, I strongly recommend you not to perform build on master (configure system as # of executors = 0).
Create slaves and perform build on slaves even when these slave nodes are on the same master machine,
so that you can separate OS accounts for slave nodes from that of master, and control easily their resources and privileges.
- When you use maven project of Jenkins,
a better idea than chroots, OS containers, or VMs may be to use the Java Security Manager for enabling isolation between projects. AFAIK it enables accesses to specific files/paths in the file system, it ensures users cannot kill other processes and can restrict access to specific network ports. This solution has the advantage that it is portable. It may also be quite easy to allow the admin of the job to configure the security settings of a job via a plugin. Then the users that "own" the job can run any shell script under the constraints imposed by the security manager.
Regarding the case of 2), at least in current Jenkins, jobs can select slaves, but slaves can't reject jobs for execution,
and slave names and labels are visible to all job authors.
- Labels and any configuration of slaves are visible only to users who have 'configure-slave permission',
but 'Label Expression' field on job configure page is kind enough to auto-complete slave labels !
I think, slave and job configuration should have credential like password for job execution on that slave.
The case of 3) may be a problem specific to Subversion plugin. (I don't know other SCM plugins)
Subversion plugin tries to store subversion credentials globally for subversion URLs specified by job configuration
and reuse these credentials automatically afterward.
So if you know only subversion URLs of other jobs,
you can access to this URLs without providing any credential!
This problem may be due to SVNkit,
but it seems more desirable and safe to set subversion credential for each job.
Of course, malicious attack by job or build-script authors is out of consideration,
but it is a big problem to allow the above things very easily or by accident.
These problems seems not so difficult to fix, and should be fixed, I believe.
Sorry if I'm wrong, please feel free to comment to, or update this page.
(I'm not so good at English, so correction of English words/expressions would be
also very appreciated :-)