[PATCH v2] Add SELinux policy for virt

[Vit Mojzis]

On 4/30/21 10:28 PM, Vit Mojzis wrote:
>
> On 4/26/21 7:31 PM, Daniel P. Berrangé wrote:
>> On Wed, Apr 07, 2021 at 06:14:58AM -0700, Vit Mojzis wrote:
>>> Sorry for the long delay. This is our first request to ship a policy 
>>> for
>>> multiple selinux stores (targeted, mls and minimum).
>>>
>>> Changes:
>>> * Replace all selinux-policy-%{policytype} dependencies with 
>>> selinux-policy-base
>>> * Add Ghost files representing installed policy modules in all 
>>> policy stores
>>> * Rewrite policy compilation script in python
>>> * Compile the policy module twice (1 version for targeted/minimum - 
>>> with
>>>    enable_mcs, and 1 for mls - with enable_mls)
>>> * Manage policy (un)installation using triggers based on which policy
>>>    type is available
>>>
>>> The new policy was only tested in "targeted" mode so far and we'll 
>>> need to make
>>> sure it works properly in "mls". As for "minimum", we know it will not
>>> work properly (as is the case of the current policy) by default (some
>>> other "contrib" policy modules need to be enabled).
>>> I'd argue there is no point trying to get it to work in "minimum",
>>> mostly because it (minimum) will be retired soon.
>> I'm wondering how SELinux is supposed to integrate with containers when
>> using a modular policy.
>>
>> Right now you can install RPMs in a container, and use selinux 
>> enforcement
>> on that container because the host OS policy provides all the rules 
>> in the
>> monolithic blob.
>> If we take this policy into libvirt, then when you install libvirt in a
>> container, there will be no selinux policy available.
>>
>> Users can't install libvirt-selinux inside the container, as it needs 
>> to be
>> built against the main policy in the host.
>>
>> User likely won't install libvirt-selinux outside the container as that
>> defeats the purpose of using containers for their deployment mechanism.
>>
>> Container based deployment of libvirt is important for both OpenStack
>> and KubeVirt.

So from discussions with respective developers i got the following:

KubeVirt runs the libvirt containers with a custom policy 
https://github.com/kubevirt/kubevirt/blob/81cb9f79e0144af0e6e43c439eab7f8dac81de31/cmd/virt-handler/virt_launcher.cil, 
that depends on libvirt module (uses svirt_sandbox_domain). Libvirt is 
only installed inside the container and there is no bind mount of 
/sys/fs/selinux. So they will need to install libvirt-daemon-selinux on 
the host.

OpenStack is currently also installing libvirt and QEMU packages only in 
"nova_libvirt" container (however there is some talk of decontainising 
libvirt in osp 17). Libvirt policy from the host system is propagated 
into the container and used to run the QEMU process as svirt_t 
(http://file.emea.redhat.com/~kchamart/SELinux_libvirt_and_QEMU_in_a_container.html). 
/sys/fs/selinux is bindmounted in this case (so it would be possible to 
install Libvirt policy module to the host machine from the container), 
but it would be better to install libvirt-daemon-selinux only on the host.

We'll need to work with both groups to make sure that their use case 
works properly with the new policy supporting split-daemon 
configuration, and that they install libvirt-daemon-selinux on the host 
machine.

>
> Honestly, I don't know how this is handled in OpenStack or KubeVirt.
>
> Normally the whole container (any processes inside) runs under 
> container_t or spc_t and you can't interact with selinux from inside 
> the container (all selinux tools would act as if selinux was 
> disabled). It is possible to bindmount /sys/fs/selinux of the host 
> system into the container. Then you can interact with system policy of 
> the host system from the container (even load policy modules).
>
> I assumed that anything container-related would be handled by the 
> container policy module (there is even a special domain for kata 
> containers).
>
> I'll try and get more information about this (Dan Walsh would probably 
> be the right person to if you wanted to investigate on your own).
>
>> Regards,
>> Daniel