Daniel J Walsh dwalsh at
Tue Sep 3 20:56:59 UTC 2013

Hash: SHA1

On 09/03/2013 03:37 PM, Jay Greguske wrote:
> On 09/03/2013 01:54 PM, Daniel J Walsh wrote:
>> 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> 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.
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the devel mailing list