You'll probably want some way to let Jenkins spin virtual machines up
and down on demand. That has been discussed here regarding VMware
ESXi guests but I'm not sure about the resolution or how it would work
with KVM.
--
Les Mikesell
lesmi...@gmail.com
From: Cristian Zamfir <zamfi...@gmail.com>
To: jenkins...@googlegroups.com
Sent: Thursday, October 6, 2011 2:14 PM
Subject: Re: no isolation between workspaces of different users (security problem)
Thanks for bringing this entire thing up. We are having exactly the same
concerns,
http://groups.google.com/group/jenkinsci-users/browse_thread/thread/b301845e0274790d#
Having 100 virtual machines around for just the purpose of being jenkins
slaves sees to be an incredible overhead to me.
The probable easiest and most lightweight way to achieve seperated
sandboxes is to have multiple tomcat instances running on the build
machine, each of them running as a seperate user.
IMHO this is a major security flaw, because it is not uncommon having
tomcat running as root and thus exposing the entire build box to
malicious tests injected via jenkins. There should be a way to
explicitly configure the *system* user that builds and tests run under.
On Fri, Oct 7, 2011 at 3:37 AM, Udo Rader <lis...@bestsolution.at> wrote:
> The probable easiest and most lightweight way to achieve seperated
> sandboxes is to have multiple tomcat instances running on the build
> machine, each of them running as a seperate user.
This is the best way, if you actually require isolated environments
and Tomcat. I provide what I think is an even easier mechanism below.
> IMHO this is a major security flaw, because it is not uncommon having
> tomcat running as root and thus exposing the entire build box to
> malicious tests injected via jenkins. There should be a way to
> explicitly configure the *system* user that builds and tests run under.
Uhhh... so, because you're too lazy to configure Tomcat properly, then
it's a Jenkins security flaw? Sorry, no. If you run any service as
root, then you're opening yourself up to just about anything; and
where is it common to run Tomcat as root? This isn't the default.
There's simply no way for Jenkins to alter capabilities for the
container which it is running under.. that job is up to you. If you
can't be bothered, I'd suggest you use one of the pre-assembled binary
packages (.rpm, .deb, etc) which already drop permissions by running
non-privileged.
The best way to achieve the kind of thing you're looking for, right
now, is to simply create a new user account for each Jenkins instance,
copy the .war file into its home directory, and execute it directly
passing in hostname and port parameters. It is easily scriptable and
provides the discussed levels of isolation.
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
Thanks for your response.
No, I am neither too lazy to configure tomcat properly nor am I
blaming/flaming anyone.
I just would like to see a possibility to run "jobs" as any configurable
system user. "A job" in that sense can be anything build related.
Invocing commands such as mvn or shell scripts in general as a user
different from the tomcat user can be easily achieved using sudo on unix
systems for example.
And I did not say that it was common running tomcat as root, I said that
it is not uncommon (note the fine difference). I am very aware that most
preconfigured servlet engines shipped by the distributions are running
under a dedicated user, yet most of them not are not chroot'ed (which is
absolutely not trivial to configure ie. for tomcat).
> The best way to achieve the kind of thing you're looking for, right
> now, is to simply create a new user account for each Jenkins instance,
> copy the .war file into its home directory, and execute it directly
> passing in hostname and port parameters. It is easily scriptable and
> provides the discussed levels of isolation.
Yes, this sounds like the most reasonable alternative so far, thanks for
this idea.
Yet still, in a default Jenkins installation users are managed within
Jenkins and those users can access each other's workspace without any
limitation. I would call this a security flaw, but please correct me if
I am wrong :)
On Fri, Oct 7, 2011 at 6:14 AM, Udo Rader <lis...@bestsolution.at> wrote:
> I just would like to see a possibility to run "jobs" as any configurable
> system user. "A job" in that sense can be anything build related.
> Invocing commands such as mvn or shell scripts in general as a user
> different from the tomcat user can be easily achieved using sudo on unix
> systems for example.
This topic comes up about once every 6 months. I wouldn't say it is
common, but it isn't uncommon ;-) Can you describe a general method
for a Java process to do sudo-like activities? I'm not aware of
anything like, or if it is possible in a Java framework.
> Yet still, in a default Jenkins installation users are managed within
> Jenkins and those users can access each other's workspace without any
> limitation. I would call this a security flaw, but please correct me if
> I am wrong :)
I wouldn't call it a security flaw, but some language is required;
maybe gap? Jenkins security mechanisms all deal with the
administration and operation of Jenkins itself, not with what Jenkins
executes. The only thing that comes to mind is enabling a Java
security manager, but I know next to nothing about this technology,
and I suspect it isn't going to fit with a general user-based
security.
Maybe you could investigate creating a general Jenkins security
manager which, when typically gets enabled at startup via -D or some
such. I do know that the security manager could restrict file access
via checkRead / checkWrite and perhaps veto any attempt to do a file
io against something outside its workspace? I don't know.
This kind of security is evidently not a high (or medium) priority for
anyone actively working on Hudson/Jenkins. You must be the change you
wish to see in the project.
I must admit that don't know too much about the internals of how Jenkins
operates. For that part, I know that Jenkins already spawns shell
processes in order to perform arbitrary tasks:
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tasks/Shell.java
The same applies for maven:
https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/tasks/Maven.java
It may not be a "general method for a Java process to do sudo-like
activities" but for those two parts it should be sufficient if those
executables were run by the logged in Jenkins-user using his/her Jenkins
credentials, e.g. by invoking the shell using su - $USER -c $COMMAND or
similar. Like I said, my knowledge about Jenkins is limited (we are only
in the process of evaluating if it will eventually fit our
requirements), so I might just miss something important.
But I understand that Jenkins is working differently right now.
> I wouldn't call it a security flaw, but some language is required;
> maybe gap? Jenkins security mechanisms all deal with the
> administration and operation of Jenkins itself, not with what Jenkins
> executes. The only thing that comes to mind is enabling a Java
> security manager, but I know next to nothing about this technology,
> and I suspect it isn't going to fit with a general user-based
> security.
Yes, I can hardly see where the Java security manager would be helpful
when build tasks and tests tasks are started via the (shell) command
line. Running shell commands requires restriction on the shell level, so
at least I can only think about either running them sudo like or
chroot'ing the shell processes.
> Maybe you could investigate creating a general Jenkins security
> manager which, when typically gets enabled at startup via -D or some
> such. I do know that the security manager could restrict file access
> via checkRead / checkWrite and perhaps veto any attempt to do a file
> io against something outside its workspace? I don't know.
>
> This kind of security is evidently not a high (or medium) priority for
> anyone actively working on Hudson/Jenkins. You must be the change you
> wish to see in the project.
Thanks for that insight, but I am definitively not sure if that task
would fit my limited shoes ;)
And if the OP is still listening: sorry for hijacking your thread ...
I think you've understood the issue and the alternatives very well. Jenkins
Jobs are executed with the userid of the process on the node where they are
running. It seems like what you're envisioning is that the Jenkins slave
process would switch to a different user before executing the job on behalf
of that user. Jenkins doesn't do that.
You correctly noted that one solution is to have slave agents which are user
specific. That has the benefit that you could run the slave agent as that
user in order to take advantage of operating system access checks for that
user. It has the disadvantage you noted, overhead required to configure
slave nodes for each user.
You could also consider "pooling" slave agents and assigning users to pools.
The users within a "pool" would still be able to see each other's work, but
not outside their pool (assuming you limited jobs to execute within only a
specific pool of users). Pooling would probably allow load balancing of
jobs between slave agents more effective and would likely reduce your
overhead to managing several pools instead of 100+ independent slave
entities.
You could also consider shifting responsibility for the problem, accepting
that if a malicious developer performs this sort of attack then it is a
management problem rather than a continuous integration problem. I'm sure
there are places where that is not acceptable (government security work,
military research work, etc.), but it is an alternative to consider if
you're not in one of those places.
Thanks,
Mark Waite
--
View this message in context: http://jenkins.361315.n4.nabble.com/no-isolation-between-workspaces-of-different-users-security-problem-tp3853930p3865252.html
Sent from the Jenkins users mailing list archive at Nabble.com.
> Hi,
> Very thanks for follwing up.
>
>> A job can also read/write Jenkins configuration files because jobs are executed with thee same user id (e.g., tomcat6).
>
> Do you mean "build on master" ?
>
> We strongly recommend our developers not to perform build on master
> (configure system as # of executors = 0),
> rather create slaves and perform build on slaves even when these slave
> nodes are on the same master machine,
> because we can easily separate OS accounts for slave nodes from that
> of master, and control thier resources and privileges.
I did not understand that one can bound a slave to an OS account. Can you please point me to the documentation where this is mentioned? It would not solve all the problems, but maybe it is good enough for some setups. The Java Security Manager seems more configurable.
>
>> I am only incidentally familiar with the Java Security Manager,
>
> Using Java Security Manager looks great,
> but I and many Jenkins users are not so familiar with that.
> So if you attach your sample settings for Java Security Manager,
> it will be very useful to us.
I do not have much experience with the Java Security Manager, but I understand that it can be used programmatically, so it could be used internally by Jenkins to enforce a configuration provided by a user. For instance, the user could select that a specific job is only allowed to access a certain port range, this setting would be parsed by Jenkins, which would get a reference to the security manager (e.g., System.getSecurityManager()) and enforce the user-provided policy setting. I did not test this, but I believe it is possible.
Thanks,
Cristi