----- Original Message ----- > From: "Robert Middleswarth" <[email protected]> > To: "Eyal Edri" <[email protected]> > Cc: "Mike Burns" <[email protected]>, [email protected] > Sent: Wednesday, July 18, 2012 10:17:36 PM > Subject: Re: Security issues when running gerrit patches on jenkins > > On 07/18/2012 03:10 PM, Eyal Edri wrote: > > > > ----- Original Message ----- > >> From: "Mike Burns" <[email protected]> > >> To: "Eyal Edri" <[email protected]> > >> Cc: "Robert Middleswarth" <[email protected]>, > >> [email protected] > >> Sent: Wednesday, July 18, 2012 8:45:05 PM > >> Subject: Re: Security issues when running gerrit patches on > >> jenkins > >> > >> On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote: > >>> ----- Original Message ----- > >>>> From: "Robert Middleswarth" <[email protected]> > >>>> To: [email protected] > >>>> 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? > >>>> > >>> i've never done this in the past. > >>> i assume we'll need to read the author email/name from the gerrit > >>> patch (before running the code) > >>> wget the whitelist page from ovirt.org and match it.. > >>> > >>> or alternatively run git log and search it there... > >>> > >>> if there isn't a match, fail the job before running any code. > >> No, I don't think we want to have failures in the main build job. > >> What > >> about a separate job that verifies the patch submitter, then > >> triggers > >> the build job. Would probably need to pass the GERRIT_REFSPEC > >> variable > >> between the 2 builds somehow. > > of course, the main job won't be touched. > > i was talking about a new job that will only be used with gerrit > > patches. > > and it can fail and give '-1' if the submitter is not authorized. > > i need to check if we can add an 'error msg' to the user with > > something like > > "Sorry, but you're not authorized to send patch to xxxx project, > > please send a request to infra/devel list"... > I think the idea was to not run until someone can take a look at the > patch. Not reject the patch. >
shouldn't be a problem to do that as well, just ignore the patch (i.e not run it in jenkins, similar to the status now) > Thanks > Robert > > > > > > >> Mike > >> > >>>> 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 > >>>>> > >>>>> > >>>>> -----BEGIN PGP SIGNATURE----- > >>>>> Version: GnuPG v1.4.12 (GNU/Linux) > >>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >>>>> > >>>>> iD8DBQFQBsrp2ZIOBq0ODEERAlfyAKDiJCl6RLXVQluAw9hsX9Uc4ftzMgCgjH6G > >>>>> 0Ejk6rXviSMbc+oiKVTjMUs= > >>>>> =3Hf2 > >>>>> -----END PGP SIGNATURE----- > >>>>> _______________________________________________ > >>>>> Infra mailing list > >>>>> [email protected] > >>>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> _______________________________________________ > >>>> Infra mailing list > >>>> [email protected] > >>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> > >>> _______________________________________________ > >>> Infra mailing list > >>> [email protected] > >>> http://lists.ovirt.org/mailman/listinfo/infra > >> > >> > > _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
