Re: Security issues when running gerrit patches on jenkins

From: "Robert Middleswarth" <robert(a)middleswarth.net&gt; To: infra(a)ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/18/2012 06:20 AM, Dan Kenigsberg wrote: >> On Wed, Jul 18, 2012 at 07:05:16AM -0400, Eyal Edri wrote: >>> Hi, >>> >>> Following last infra meeting, i want to open for discussion the >>> security issues that may arise if we allow Jenkins to run jobs >>> (i.e any code) with every gerrit patch. >>> >>> The problem: >>> >>> In theory, any user that is registered to gerrit might send a >>> patch to any ovirt project. That code might contain malicious >>> code, malware, harmfull or just not-related ovirt code that he >>> wants to use our resources for it. Even though we use limited >>> sudo on hosts, we can't be sure an exploit will be used against >>> one of the jenkins slaves. >>> >>> >>> The proposed solutions: >>> >>> - black-listing authors (published on ovirt.org?) - white-listing >>> authors (published on ovirt.org?) - auto approve patch via >>> comparing to lastest commits - check if author recent patches >>> were approved in the past? >>> >>> adding dan since he raised this issue when we wanted to add vdsm >>> gerrit tests. >> In my opinion, we can trust anyone who has already contributed >> code >> to the relevant project. We can even say: someone who contributed >> more than 3 commits over a month ago. > This seems like a reasonable approach. Trust people first, and it's > fine to have a method to untrust people if the need arises. That > shouldn't surprise or disappoint anyone - it's just simple sanity. > > The alternatives are to build untrust in to the process from the > start, which becomes a barrier to getting things done, and > perpetuates > a culture of untrust. > > I just remind myself, if someone is going to worm their way in to > our > trust to run malicious code on our Jenkins instances, there is so > much > more damage they can do with that trust. > > Trust is like fertilizer, water, and sunshine in the garden - it > makes > amazing things grow. :) I am on the opposite side of this issue. Maybe I have been attacked by 1 to many bot's or been a manager when someone I know and trusted stole from the company. I need trust to be earned so I +1 on whitelist. With that said I think getting on the whitelist should be pretty easy. We are not talking about blocking there commit's we are talking about should the automated system run test/code against there patch. I am still learning Jekins when using a whitelist is there a way to flag commits for users not in the list? I wonder if there is some way to create a list that someone can go though and whitelist the user or reject the user for commits not in the whitelist?

Thanks Robert > > - - Karsten > - -- > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > http://TheOpenSourceWay.org .^\ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra