[engineering.redhat.com #319333] Re: [Security] System job to deploy rpms

[David Caro]

On 10/12, Eyal Edri wrote:
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: secalert at redhat.com
> > Cc: security at ovirt.org, infra at 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 at 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,


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.


> 
> Eyal.
> 
> > 
> > > 
> > 
> > 
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra

-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20141013/6628bd52/attachment.sig>