[PATCH v2] Add SELinux policy for virt

[Vit Mojzis]

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.

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