Security issues when running gerrit patches on jenkins
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. thoughts? Eyal.
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. However, no trust should be perpetual (passwords get lost, laptops are lost, people go crazy..) so I suggest to have a blacklist of people we no longer trust. It would be easier to maintain such a list as a (locked) wiki page, so peole can see that they are unrusted, and can apeal ("I'm sane today, lemme run stuff on your slaves!"). Note that I don't expect this blacklist to be used in the near future, but when we'd need it, we'd need it fast. So we'd better prepare ahead of time. Regards, Dan.
-----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. :) - - 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-----
-----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
On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----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
On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: 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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----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
On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: 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. 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 Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@ovirt.org 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" <robert@middleswarth.net> To: infra@ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----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
On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: 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"...
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 Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On 07/18/2012 03:10 PM, Eyal Edri wrote:
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@ovirt.org Sent: Wednesday, July 18, 2012 8:45:05 PM Subject: Re: Security issues when running gerrit patches on jenkins
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----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
On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: 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
On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote: 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. 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 Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: "Mike Burns" <mburns@redhat.com>, infra@ovirt.org 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:
From: "Mike Burns" <mburns@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@ovirt.org Sent: Wednesday, July 18, 2012 8:45:05 PM Subject: Re: Security issues when running gerrit patches on jenkins
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Wednesday, July 18, 2012 8:00:44 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----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
On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: 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
On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote: 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
----- Original Message ----- 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 Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Am 18.07.2012 um 13:00 schrieb Robert Middleswarth:
I need trust to be earned so I +1 on whitelist. With that said I think getting on the whitelist should be pretty easy.
Isn't that what you usually do on projects - have the first few commits not directly go to master but being reviewed by an existing committer and then giving full commit access to a new user? So I think that fits in and fits with what new committers are used to. Many of them actually would be scared if they got commit access from day 1. Heiko
On Wed, 2012-07-18 at 13:34 -0400, Heiko W.Rupp wrote:
Am 18.07.2012 um 13:00 schrieb Robert Middleswarth:
I need trust to be earned so I +1 on whitelist. With that said I think getting on the whitelist should be pretty easy.
Isn't that what you usually do on projects - have the first few commits not directly go to master but being reviewed by an existing committer and then giving full commit access to a new user? So I think that fits in and fits with what new committers are used to. Many of them actually would be scared if they got commit access from day 1.
It's not commit access that is being discussed. We're not giving that away easily. Jenkins provides the ability to trigger builds/tests on patch submission (just submission, not commit). A savvy attacker could write a patch that could cause the tests to compromise the jenkins slave machine. The whitelist being proposed is a whitelist for running the build/test based on who submitted the patch. Mike
Heiko
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Am 18.07.2012 um 13:43 schrieb Mike Burns:
It's not commit access that is being discussed. We're not giving that away easily. Jenkins provides the ability to trigger builds/tests on patch submission (just submission, not commit). A savvy attacker could write a patch that could cause the tests to compromise the jenkins slave machine. The whitelist being proposed is a whitelist for running the build/test based on who submitted the patch.
I got that. I am saying that the way for new committers is similar to this whitelisting pattern. Meaning that at the start their contributions are not auto-committed. And then after some time they end up on a whitelist (== commit access). And if they fail a few times miserably, the commit access is revoked. That would match the pattern of not automatically running every submission directly on gerrit until they have proven that they know what they are doing. -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
Am 18.07.2012 um 15:57 schrieb Heiko W.Rupp:
That would match the pattern of not automatically running every submission directly on gerrit until they have proven that they know what they are doing.
Which is what they are used with not getting full commit access on day 1. -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht München HRB 153243 Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/18/2012 10:00 AM, Robert Middleswarth wrote:
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?
Perhaps this is just an example of my limited dimensional thinking around SCMs. I tend to think by default, "There should be a well described pathway to committer status. Once achieved, you can commit, that's it." Old school thinking. :) However, I get that more complex infrastructure may have other considerations. In Fedora, for example, things went from a wide open SCM where anyone could commit to any package, to a more segregated system with the idea of an over-packager status that one can attain, which provides the now rare ability to commit to any package. Similarly here, oVirt may say, "Fine, you can commit code to the main git repo, but you have to earn Level Q to be able to kick-off automated testing." I just want us to be careful how we contextualize, too. While trust is one reason we don't give root to everyone, another reason is we want to be sure they know how to be safe and sane in that position. People may need e.g. training or testing that they are not going to accidentally do something that makes Jenkins fall down and cry. - - 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/ iD8DBQFQByDf2ZIOBq0ODEERAp3OAJ9JTiBDnhgW9zRbwD9T17S55FAbeQCg4XaD C1qHTKUnqo6kgixjOUbQ4A4= =0tIA -----END PGP SIGNATURE-----
On 07/18/2012 11:47 PM, Karsten 'quaid' Wade wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 10:00 AM, Robert Middleswarth wrote:
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?
Perhaps this is just an example of my limited dimensional thinking around SCMs. I tend to think by default, "There should be a well described pathway to committer status. Once achieved, you can commit, that's it." Old school thinking. :) However, I get that more complex infrastructure may have other considerations. In Fedora, for example, things went from a wide open SCM where anyone could commit to any package, to a more segregated system with the idea of an over-packager status that one can attain, which provides the now rare ability to commit to any package. Similarly here, oVirt may say, "Fine, you can commit code to the main git repo, but you have to earn Level Q to be able to kick-off automated testing."
I just want us to be careful how we contextualize, too. While trust is one reason we don't give root to everyone, another reason is we want to be sure they know how to be safe and sane in that position. People may need e.g. training or testing that they are not going to accidentally do something that makes Jenkins fall down and cry.
I wouldn't view infra as a single project, rather several sub projects, each with their own set of skills as each service requires expertise with a different technology.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/18/2012 04:05 AM, 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.
- white-listing authors (published on ovirt.org?) ...
I think the consensus we are leaning toward is this: * Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. * Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value. Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"? For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? - - 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/ iD8DBQFQF+2d2ZIOBq0ODEERAmxqAKDNHOfAEHwfTbQz/Yubo3iApBdUYwCePkPC D9M+eLnNAaUv2Y0+yVWA+3o= =HmZo -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 04:05 AM, 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.
- white-listing authors (published on ovirt.org?) ... I think the consensus we are leaning toward is this:
* Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding themselves. * Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value.
Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"?
For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? That isn't a black list that is an itemized white list and at this stage I don't see a point to it. What tests / jobs would your run diff from
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits. 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/
iD8DBQFQF+2d2ZIOBq0ODEERAmxqAKDNHOfAEHwfTbQz/Yubo3iApBdUYwCePkPC D9M+eLnNAaUv2Y0+yVWA+3o= =HmZo -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 04:05 AM, 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.
- white-listing authors (published on ovirt.org?) ... I think the consensus we are leaning toward is this:
* Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding
* Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value.
Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"?
For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? That isn't a black list that is an itemized white list and at this stage I don't see a point to it. What tests / jobs would your run diff from
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: themselves. the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits.
btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well.
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/
iD8DBQFQF+2d2ZIOBq0ODEERAmxqAKDNHOfAEHwfTbQz/Yubo3iApBdUYwCePkPC D9M+eLnNAaUv2Y0+yVWA+3o= =HmZo -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On 07/31/2012 01:19 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 04:05 AM, 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.
- white-listing authors (published on ovirt.org?) ... I think the consensus we are leaning toward is this:
* Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding
* Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value.
Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"?
For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? That isn't a black list that is an itemized white list and at this stage I don't see a point to it. What tests / jobs would your run diff from
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: themselves. the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits.
btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well.
I haven't looked at the plug-in structure so if you can reuse the interface for the admin matrix and just let you select people from the people list that would be a great add-on.
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/
iD8DBQFQF+2d2ZIOBq0ODEERAmxqAKDNHOfAEHwfTbQz/Yubo3iApBdUYwCePkPC D9M+eLnNAaUv2Y0+yVWA+3o= =HmZo -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org Sent: Tuesday, July 31, 2012 8:35:25 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 07/31/2012 01:19 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 04:05 AM, 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.
- white-listing authors (published on ovirt.org?) ... I think the consensus we are leaning toward is this:
* Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding
* Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value.
Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"?
For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? That isn't a black list that is an itemized white list and at this stage I don't see a point to it. What tests / jobs would your run diff from
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: themselves. the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits.
btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well.
I haven't looked at the plug-in structure so if you can reuse the interface for the admin matrix and just let you select people from the people list that would be a great add-on.
i was thinking on the specific use case of gerrit plugin, that will allow triggering jobs only for certain email/user name. i'll ask on jenkins list if this feature is something they consider or we can contribute.
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/
iD8DBQFQF+2d2ZIOBq0ODEERAmxqAKDNHOfAEHwfTbQz/Yubo3iApBdUYwCePkPC D9M+eLnNAaUv2Y0+yVWA+3o= =HmZo -----END PGP SIGNATURE----- _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
On 08/01/2012 02:56 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org Sent: Tuesday, July 31, 2012 8:35:25 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 07/31/2012 01:19 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 04:05 AM, 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.
- white-listing authors (published on ovirt.org?) ... I think the consensus we are leaning toward is this:
* Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding
* Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value.
Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"?
For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? That isn't a black list that is an itemized white list and at this stage I don't see a point to it. What tests / jobs would your run diff from
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: themselves. the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits.
btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well.
I haven't looked at the plug-in structure so if you can reuse the interface for the admin matrix and just let you select people from the people list that would be a great add-on.
i was thinking on the specific use case of gerrit plugin, that will allow triggering jobs only for certain email/user name. i'll ask on jenkins list if this feature is something they consider or we can contribute.
wouldn't it be easier to maintain the whitelist via a git repo on gerrit?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@ovirt.org Sent: Wednesday, August 1, 2012 4:08:41 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 08/01/2012 02:56 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org Sent: Tuesday, July 31, 2012 8:35:25 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 07/31/2012 01:19 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/18/2012 04:05 AM, 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. > > - white-listing authors (published on ovirt.org?) ... I think the consensus we are leaning toward is this:
* Use a whitelist to identify who can have Jenkins jobs triggered when a patch hits Gerrit. * Keep the whitelist on the wiki, so it's clear who has access, and the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding
* Current whitelist is built from current committers (from git log). ** compare the whitelist with the current GERRIT_AUTHOR or similar value.
Do we want to build-in the ability to check a blacklist, too? Or just use "absence from whitelist"?
For example, is there going to be a desire to have someone not be able to automatically run a test on certain parts of the code, but yes on others? That isn't a black list that is an itemized white list and at
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: themselves. this stage I don't see a point to it. What tests / jobs would your run diff from the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits.
btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well.
I haven't looked at the plug-in structure so if you can reuse the interface for the admin matrix and just let you select people from the people list that would be a great add-on.
i was thinking on the specific use case of gerrit plugin, that will allow triggering jobs only for certain email/user name. i'll ask on jenkins list if this feature is something they consider or we can contribute.
wouldn't it be easier to maintain the whitelist via a git repo on gerrit?
you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it.
On 08/01/2012 09:31 AM, Eyal Edri wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@ovirt.org Sent: Wednesday, August 1, 2012 4:08:41 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 08/01/2012 02:56 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org Sent: Tuesday, July 31, 2012 8:35:25 PM Subject: Re: Security issues when running gerrit patches on jenkins
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: infra@ovirt.org Sent: Tuesday, July 31, 2012 7:55:49 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/18/2012 04:05 AM, 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. >> >> - white-listing authors (published on ovirt.org?) ... > I think the consensus we are leaning toward is this: > > * Use a whitelist to identify who can have Jenkins jobs > triggered > when > a patch hits Gerrit. > * Keep the whitelist on the wiki, so it's clear who has access, > and > the list can be used by all Jenkins hosts. I would prefer wordpress to prevent someone from just adding themselves. > * Current whitelist is built from current committers (from git > log). > ** compare the whitelist with the current GERRIT_AUTHOR or > similar > value. > > Do we want to build-in the ability to check a blacklist, too? > Or > just > use "absence from whitelist"? > > For example, is there going to be a desire to have someone not > be > able > to automatically run a test on certain parts of the code, but > yes > on > others? That isn't a black list that is an itemized white list and at this stage I don't see a point to it. What tests / jobs would your run diff from the kinda trusted list vs the completely untrusted list? It not like the list is going to be used to allow people to change Jenkins it is just going to be there to allow commit's to generate builds. If we have a list of people we fell is safe enough to run test against how much more exposure will there be also allowing auto builds? And if we do come up with test that we feel can be run on all commits we would run them on all not just a small subset of commits.
btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well. I haven't looked at the plug-in structure so if you can reuse the interface for the admin matrix and just let you select people from
On 07/31/2012 01:19 PM, Eyal Edri wrote: the people list that would be a great add-on. i was thinking on the specific use case of gerrit plugin, that will allow triggering jobs only for certain email/user name. i'll ask on jenkins list if this feature is something they consider or we can contribute.
wouldn't it be easier to maintain the whitelist via a git repo on gerrit? you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it.
Actually makes a lot more since. That allows the projects the ability to manage there own list. -- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
On 08/01/2012 04:35 PM, Robert Middleswarth wrote:
On 08/01/2012 09:31 AM, Eyal Edri wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Robert Middleswarth" <robert@middleswarth.net>, infra@ovirt.org Sent: Wednesday, August 1, 2012 4:08:41 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 08/01/2012 02:56 PM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "Eyal Edri" <eedri@redhat.com> Cc: infra@ovirt.org Sent: Tuesday, July 31, 2012 8:35:25 PM Subject: Re: Security issues when running gerrit patches on jenkins
----- Original Message ----- > From: "Robert Middleswarth" <robert@middleswarth.net> > To: infra@ovirt.org > Sent: Tuesday, July 31, 2012 7:55:49 PM > Subject: Re: Security issues when running gerrit patches on > jenkins > > On 07/31/2012 10:37 AM, Karsten 'quaid' Wade wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/18/2012 04:05 AM, 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. >>> >>> - white-listing authors (published on ovirt.org?) ... >> I think the consensus we are leaning toward is this: >> >> * Use a whitelist to identify who can have Jenkins jobs >> triggered >> when >> a patch hits Gerrit. >> * Keep the whitelist on the wiki, so it's clear who has access, >> and >> the list can be used by all Jenkins hosts. > I would prefer wordpress to prevent someone from just adding > themselves. >> * Current whitelist is built from current committers (from git >> log). >> ** compare the whitelist with the current GERRIT_AUTHOR or >> similar >> value. >> >> Do we want to build-in the ability to check a blacklist, too? >> Or >> just >> use "absence from whitelist"? >> >> For example, is there going to be a desire to have someone not >> be >> able >> to automatically run a test on certain parts of the code, but >> yes >> on >> others? > That isn't a black list that is an itemized white list and at > this > stage > I don't see a point to it. What tests / jobs would your run > diff > from > the kinda trusted list vs the completely untrusted list? It not > like > the > list is going to be used to allow people to change Jenkins it is > just > going to be there to allow commit's to generate builds. If we > have a > list of people we fell is safe enough to run test against how > much > more > exposure will there be also allowing auto builds? And if we do > come > up > with test that we feel can be run on all commits we would run > them > on > all not just a small subset of commits. > btw, this kind of logic might justify a jenkins plugin, or at least an extension to the gerrit trigger plugin. it might interest other people as well. I haven't looked at the plug-in structure so if you can reuse the interface for the admin matrix and just let you select people from
On 07/31/2012 01:19 PM, Eyal Edri wrote: the people list that would be a great add-on. i was thinking on the specific use case of gerrit plugin, that will allow triggering jobs only for certain email/user name. i'll ask on jenkins list if this feature is something they consider or we can contribute.
wouldn't it be easier to maintain the whitelist via a git repo on gerrit? you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it.
Actually makes a lot more since. That allows the projects the ability to manage there own list.
i don't think we need a per project list, we can start with one list. was just thinking if you want a plugin, you'll need to point it to a file/git repo with the list, rather than to a wiki.
On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth wrote:
On 08/01/2012 09:31 AM, Eyal Edri wrote:
Itamar Heim wrote:
wouldn't it be easier to maintain the whitelist via a git repo on gerrit?
you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it.
Actually makes a lot more since. That allows the projects the ability to manage there own list.
Can't we extract this from an authors file? Looking at vdsm/AUTHORS[1] it looks fairly easy. Another thing I can imagine is that someone is not whitelisted but his/her patch receives recieves a +1 from a whitelisted reviewer it can be built as well. It would be built anyway if it gets accepted and now jenkins can give -1 if it fails unit tests. Maybe at +2, but that leaves very little time to actually build it because often it will get merged straight away. [1]: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD
----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt@kohlvanwijngaarden.nl> To: infra@ovirt.org Sent: Wednesday, August 1, 2012 4:50:03 PM Subject: Re: Security issues when running gerrit patches on jenkins
On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth wrote:
On 08/01/2012 09:31 AM, Eyal Edri wrote:
Itamar Heim wrote:
wouldn't it be easier to maintain the whitelist via a git repo on gerrit?
you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it.
Actually makes a lot more since. That allows the projects the ability to manage there own list.
Can't we extract this from an authors file? Looking at vdsm/AUTHORS[1] it looks fairly easy.
Another thing I can imagine is that someone is not whitelisted but his/her patch receives recieves a +1 from a whitelisted reviewer it can be built as well. It would be built anyway if it gets accepted and now jenkins can give -1 if it fails unit tests. Maybe at +2, but that leaves very little time to actually build it because often it will get merged straight away.
usually jenkins give -1 if a job fails or 'verify' if it works.
[1]: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth wrote:
On 08/01/2012 09:31 AM, Eyal Edri wrote:
Itamar Heim wrote:
wouldn't it be easier to maintain the whitelist via a git repo on gerrit? you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it. Actually makes a lot more since. That allows the projects the ability to manage there own list. Can't we extract this from an authors file? Looking at vdsm/AUTHORS[1] it looks fairly easy. That would be a bad idea. All someone would need to do is add
On 08/01/2012 09:50 AM, Ewoud Kohl van Wijngaarden wrote: themselves to that list?
Another thing I can imagine is that someone is not whitelisted but his/her patch receives recieves a +1 from a whitelisted reviewer it can be built as well. It would be built anyway if it gets accepted and now jenkins can give -1 if it fails unit tests. Maybe at +2, but that leaves very little time to actually build it because often it will get merged straight away.
That does sound useful once someone not on the white list gets a +1 it auto test as we can assume anyone reviewing is trusted enough to not +1 a dangerous patch. Of curse this adds even more complexity in a plug-in. Although not specific enough to make the plug-in not reusable.
[1]: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Thanks Robert Middleswarth @rmiddle (twitter/IRC)
On 08/01/2012 04:56 PM, Robert Middleswarth wrote:
On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth wrote:
On 08/01/2012 09:31 AM, Eyal Edri wrote:
Itamar Heim wrote:
wouldn't it be easier to maintain the whitelist via a git repo on gerrit? you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it. Actually makes a lot more since. That allows the projects the ability to manage there own list. Can't we extract this from an authors file? Looking at vdsm/AUTHORS[1] it looks fairly easy. That would be a bad idea. All someone would need to do is add
On 08/01/2012 09:50 AM, Ewoud Kohl van Wijngaarden wrote: themselves to that list?
lets start with something... worst case someone will send a patch without jenkins auto reviewing it once or twice - important thing is it will get 99.9% of the patches reviewed by jenkins
Another thing I can imagine is that someone is not whitelisted but his/her patch receives recieves a +1 from a whitelisted reviewer it can be built as well. It would be built anyway if it gets accepted and now jenkins can give -1 if it fails unit tests. Maybe at +2, but that leaves very little time to actually build it because often it will get merged straight away. That does sound useful once someone not on the white list gets a +1 it auto test as we can assume anyone reviewing is trusted enough to not +1 a dangerous patch. Of curse this adds even more complexity in a plug-in. Although not specific enough to make the plug-in not reusable. [1]: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Robert Middleswarth" <robert@middleswarth.net> Cc: infra@ovirt.org Sent: Wednesday, August 1, 2012 5:01:10 PM Subject: Re: Security issues when running gerrit patches on jenkins
On 08/01/2012 04:56 PM, Robert Middleswarth wrote:
On Wed, Aug 01, 2012 at 09:35:39AM -0400, Robert Middleswarth wrote:
On 08/01/2012 09:31 AM, Eyal Edri wrote:
Itamar Heim wrote:
wouldn't it be easier to maintain the whitelist via a git repo on gerrit? you mean instead of putting it on a wiki page? yes, make sense to maintain a .txt file per project with the whitelist in it. Actually makes a lot more since. That allows the projects the ability to manage there own list. Can't we extract this from an authors file? Looking at vdsm/AUTHORS[1] it looks fairly easy. That would be a bad idea. All someone would need to do is add
On 08/01/2012 09:50 AM, Ewoud Kohl van Wijngaarden wrote: themselves to that list?
lets start with something... worst case someone will send a patch without jenkins auto reviewing it once or twice - important thing is it will get 99.9% of the patches reviewed by jenkins
OK. i opened a feature request for it here [1] for now i imagine we can implement it with some bash code in a jenkins job, and we can also try to send a patch for it to the gerrit trigger plugin [2] [1] https://issues.jenkins-ci.org/browse/JENKINS-14655 [2] https://github.com/jenkinsci/gerrit-trigger-plugin
Another thing I can imagine is that someone is not whitelisted but his/her patch receives recieves a +1 from a whitelisted reviewer it can be built as well. It would be built anyway if it gets accepted and now jenkins can give -1 if it fails unit tests. Maybe at +2, but that leaves very little time to actually build it because often it will get merged straight away. That does sound useful once someone not on the white list gets a +1 it auto test as we can assume anyone reviewing is trusted enough to not +1 a dangerous patch. Of curse this adds even more complexity in a plug-in. Although not specific enough to make the plug-in not reusable. [1]: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=AUTHORS;hb=HEAD _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
participants (8)
-
Dan Kenigsberg -
Ewoud Kohl van Wijngaarden -
Eyal Edri -
Heiko W.Rupp -
Itamar Heim -
Karsten 'quaid' Wade -
Mike Burns -
Robert Middleswarth