-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/03/2013 03:37 PM, Jay Greguske wrote: > 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@xxxxxxxxxx> 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? > > - Jay > I am confident it will protect the host better then we do now. You still end up running a root process on the system and depending on what capabilities we have to give the actual build procedure will determine the protection. If we could at least get the systems running in permissive mode and the mock build running as mock_t we could look at the avc's that are generated and get an idea of the actual privs required. If we can separate mock into to sections, one to do the setup as a priv process, and the second part to do execute the code that was uploaded by the user, mock_t and mock_confined_t, we could probably lock the system down tighter. This is a little different then openshift in that we are allowing them to run as root. Once we have containers implemented on RHEL7 we would want to also take advantage of running the mock environments in a container with SELinux. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlImTRsACgkQrlYvE4MpobMnFQCY5KcgVJOWtV+U3/cxUpnkG/2G nwCg2O+b1vSExezvjYs0Thqk75xS6pw= =5GBO -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
