COPR

[Michael Scherer]

Le mardi 03 septembre 2013 à 15:37 -0400, Jay Greguske a écrit :
> On 09/03/2013 01:54 PM, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 09/03/2013 12:29 PM, Michael scherer wrote:
> >> On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
> >>> On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske <jgregusk at redhat.com>
> >>> wrote:
> >>>
> >>>> If we had SELinux policy enabled on the builders and used MLS on the 
> >>>> chroots that would mitigate chroot-to-chroot attacks. I'm not sure if 
> >>>> policy could prevent a chroot'ed process from getting access to the 
> >>>> builder's certificate. If it could, I think getting SELinux working on 
> >>>> the builders would be an easier path than re-writing koji to use VMs.
> >>>>
> >>>> Maybe someone with more expertise could comment on the latter issue.
> >>>
> >>> In the past we had selinux disabled on the builders, as mock didn't 
> >>> handle selinux very well at all and there were issues. (even in 
> >>> permissive mode).
> >>>
> >>> With this switch to Fedora 19 for builders, we also enabled selinux in 
> >>> permissive mode to gather information on any outstanding issues/avcs.
> >>>
> >>> Ideally I would like to get them all to enforcing and make sure we lock 
> >>> down the builds as much as we are able from the vm.
> >>
> >> the main issue is that mock should do the transition to a different domain
> >> once it run anything in chroot. I do have a patch but I was not able to
> >> make a policy for the transition ( or my patch is buggy ) and I didn't look
> >> at it since a few weeks. I can send it if someone want to take a look.
> >>
> > Yes The builders should run each mock with a unique MCS Label and then lock
> > them down with SELinux.  I would be willing to help with this.
> > 
> > This would be the easiest solution to the problem of separating out the chroots.
> > 
> 
> Are you confident we can protect the host itself from attacks from a
> mock chroot?

That's what Openshift Online use, and according to Dan, it resisted so
far, and not because no one tried.

You have to balance the density/efficiency/overhead vs the protection.
Something like cubes running in a VM over a VM from a different
technology would be more secure than a regular shared ssh server, but
there is a price :)

-- 
Michael Scherer