Re: [PATCH v2] Add SELinux policy for virt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux