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