[engineering.redhat.com #319333] Re: [Security] System job to deploy rpms
On Mon Oct 13 04:56:13 2014, dcaroest@redhat.com wrote:
On 10/12, Eyal Edri wrote:
----- 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]
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
infrastructure for the oVirt project, or is this code going into
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
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
System job to deploy rpms pertaining to the the oVirt this is a 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,
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.
This seems reasonable to me. If you're at all unsure of uncomfortable I do suggest reaching out to infosec, but nothing described in this or the prior mail have any red flags leaping out at me. -- Vincent Danen / Red Hat Product Security
participants (1)
-
Red Hat Product Security