System job to deploy rpms
Hello everyone. I've created a small job (not yet enabled) that gets an rpm and then deploys it to the static repo at resources.ovirt.org for this I've sent this patch http://gerrit.ovirt.org/#/c/33863/ that will add the "resources" user. it will have permissions only for the static rpms directory and will scp the files to there. is it acceptable by everybody security-wise? thanks Ohad
Il 08/10/2014 12:02, Ohad Basan ha scritto:
Hello everyone.
I've created a small job (not yet enabled) that gets an rpm and then deploys it to the static repo at resources.ovirt.org for this I've sent this patch http://gerrit.ovirt.org/#/c/33863/ that will add the "resources" user. it will have permissions only for the static rpms directory and will scp the files to there. is it acceptable by everybody security-wise?
Adding security list to the loop.
thanks
Ohad _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On Wed Oct 08 08:35:15 2014, sbonazzo@redhat.com wrote:
Il 08/10/2014 12:02, Ohad Basan ha scritto:
Hello everyone.
I've created a small job (not yet enabled) that gets an rpm and then deploys it to the static repo at resources.ovirt.org for this I've sent this patch http://gerrit.ovirt.org/#/c/33863/ that will add the "resources" user. it will have permissions only for the static rpms directory and will scp the files to there. is it acceptable by everybody security-wise?
Adding security list to the loop.
Hi, thanks for this. I'm a bit confused though. Is this pertaining to the infrastructure for the oVirt project, or is this code going into the oVirt code itself that is then consumed by downstream users? I only ask because of the reference to resources.ovirt.org so I'm unsure whether this is a code question or an infrastructure question. Can you please advise? -- Vincent Danen / Red Hat Product Security
Il 08/10/2014 18:18, Red Hat Product Security ha scritto:
On Wed Oct 08 08:35:15 2014, sbonazzo@redhat.com wrote:
Il 08/10/2014 12:02, Ohad Basan ha scritto:
Hello everyone.
I've created a small job (not yet enabled) that gets an rpm and then deploys it to the static repo at resources.ovirt.org for this I've sent this patch http://gerrit.ovirt.org/#/c/33863/ that will add the "resources" user. it will have permissions only for the static rpms directory and will scp the files to there. is it acceptable by everybody security-wise?
Adding security list to the loop.
Hi, thanks for this. I'm a bit confused though. Is this pertaining to the infrastructure for the oVirt project, or is this code going into the oVirt code itself that is then consumed by downstream users? I only ask because of the reference to resources.ovirt.org so I'm unsure whether this is a code question or an infrastructure question.
Can you please advise?
It's infrastructure question
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
----- Original Message -----
From: "Sandro Bonazzola" <sbonazzo@redhat.com> To: secalert@redhat.com Cc: security@ovirt.org, infra@ovirt.org Sent: Thursday, October 9, 2014 9:09:20 AM Subject: Re: [engineering.redhat.com #319333] Re: [Security] System job to deploy rpms
Il 08/10/2014 18:18, Red Hat Product Security ha scritto:
On Wed Oct 08 08:35:15 2014, sbonazzo@redhat.com wrote:
Il 08/10/2014 12:02, Ohad Basan ha scritto:
Hello everyone.
I've created a small job (not yet enabled) that gets an rpm and then deploys it to the static repo at resources.ovirt.org for this I've sent this patch http://gerrit.ovirt.org/#/c/33863/ that will add the "resources" user. it will have permissions only for the static rpms directory and will scp the files to there. is it acceptable by everybody security-wise?
Adding security list to the loop.
Hi, thanks for this. I'm a bit confused though. Is this pertaining to the infrastructure for the oVirt project, or is this code going into the oVirt code itself that is then consumed by downstream users? I only ask because of the reference to resources.ovirt.org so I'm unsure whether this is a code question or an infrastructure question.
Can you please advise?
It's infrastructure question
let me try to clarify. today our continuous delivery process is async partially: - jenkins.ovirt.org builds and publish the rpms into resources.ovirt.org under jenkins home (unprivileged user). - a cron job scans the target dir and checks if new rpms are there (via flag used by the script) and updates the repos accordingly. the idea behind this is not to allow direct access from jenkins to resources.ovirt.org via ssh. now what ohad is suggesting is to change the process and ALLOW direct access to certain repositories under resources.ovirt.org, with the following changes: - new user will be used - resources - the user will have limited sudo access only to read/write to the relevant repository (static repos) - no cron job will run async to update it. so the question is are we comfortable with this change? is it safe or has the same security level as the current async one? if its safe we might consider changing the original flow as well to be synced and not use a cron job. your input is appreciated, Eyal.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--b0op/nKJ9CeIhp9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/12, Eyal Edri wrote: >=20 >=20 > ----- Original Message ----- > > From: "Sandro Bonazzola" <sbonazzo@redhat.com> > > To: secalert@redhat.com > > Cc: security@ovirt.org, infra@ovirt.org > > Sent: Thursday, October 9, 2014 9:09:20 AM > > Subject: Re: [engineering.redhat.com #319333] Re: [Security] System job= to deploy rpms > >=20 > > Il 08/10/2014 18:18, Red Hat Product Security ha scritto: > > > On Wed Oct 08 08:35:15 2014, sbonazzo@redhat.com wrote: > > >> Il 08/10/2014 12:02, Ohad Basan ha scritto: > > >>> Hello everyone. > > >>> > > >>> I've created a small job (not yet enabled) > > >>> that gets an rpm and then deploys it to the static repo at > > >> resources.ovirt.org > > >>> for this I've sent this patch http://gerrit.ovirt.org/#/c/33863/ > > >>> that will add the "resources" user. it will have permissions only > > >> for the static rpms directory and will scp the files to there. > > >>> is it acceptable by everybody security-wise? > > >>> > > >> > > >> Adding security list to the loop. > > >=20 > > > Hi, thanks for this. I'm a bit confused though. Is this pertaining = to the > > > infrastructure for the oVirt project, or is this code going into the = oVirt > > > code itself that is then consumed by downstream users? I only ask be= cause > > > of the reference to resources.ovirt.org so I'm unsure whether this is= a > > > code question or an infrastructure question. > > >=20 > > > Can you please advise? > >=20 > > It's infrastructure question >=20 > let me try to clarify. > today our continuous delivery process is async partially: > - jenkins.ovirt.org builds and publish the rpms into resources.ovirt.org= under jenkins home (unprivileged user). > - a cron job scans the target dir and checks if new rpms are there (via = flag used by the script) and updates the repos accordingly. >=20 > the idea behind this is not to allow direct access from jenkins to resour= ces.ovirt.org via ssh. >=20 > now what ohad is suggesting is to change the process and ALLOW direct acc= ess to certain repositories under resources.ovirt.org, with the following c= hanges: > - new user will be used - resources > - the user will have limited sudo access only to read/write to the relev= ant repository (static repos) > - no cron job will run async to update it. >=20 > so the question is are we comfortable with this change? is it safe or has= the same security level as the current async one?=20 > if its safe we might consider changing the original flow as well to be sy= nced and not use a cron job. >=20 > your input is appreciated, As far as I know, the only reason we had to use the cron (kiril might know better, but he does not work with us anymore) was to avoid exposing the signing key for the packages to the jenkins ssh user, but that part was never automated anyhow and the nightly-static packages are not signed. So I think that creating a new user without privileges to mess anything up (only access to the nightly repos) is as secure as the cron approach, but more convenient. In the future I'm thinking on using a simple web service to deploy the rpms, that way the clients do not need ssh access to the machine at all. But that's not ready yet. >=20 > Eyal. >=20 > >=20 > > >=20 > >=20 > >=20 > > -- > > Sandro Bonazzola > > Better technology. Faster innovation. Powered by community collaboratio= n. > > See how it works at redhat.com > > _______________________________________________ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > >=20 > _______________________________________________ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --b0op/nKJ9CeIhp9z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUO6/HAAoJEEBxx+HSYmnDmHYH/2FezDvHuE8LJAROrlWCEnhr dl5Jk12b0XsiX3y8oQT61HI3c1fpDtgUlgkwKHpJa0ukE4SPZBVyXsmucMDdDHmZ XFDhGSGX9GdtqUf5A9rO4tOnXfhDdTS6RwuUJJQ5Toz+BWu8/+eQS2pZUVCbYCS0 Bg7X/RRpsakpKCS+bqENOkWNcY194UWx5egwx2UDk7G1pW4UmKgCYN8TxJq3jVVG kqFS+bnPOMX9sJXErisBi1P/x0hIF7ojB+Jmhf4TgIv7NamB2UaYGGNbzK5Li417 DJzL6H7Ethxdm8HkKzf/KC8CPRztPdowUhq8/X13Rce10K7POg2jWvN/DbfpOp8= =GNDY -----END PGP SIGNATURE----- --b0op/nKJ9CeIhp9z--
participants (5)
-
David Caro -
Eyal Edri -
Ohad Basan -
Red Hat Product Security -
Sandro Bonazzola