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
