Security issues when running gerrit patches on jenkins

[Robert Middleswarth]

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
>
>
> -----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
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra