On 24. 05. 21 14:36, Daniel P. Berrangé wrote:
On Mon, May 24, 2021 at 05:25:19AM -0700, Andrea Bolognani wrote:
On Fri, May 21, 2021 at 03:37:00PM +0100, Daniel P. Berrangé wrote:
On Fri, May 21, 2021 at 04:22:59PM +0200, Vit Mojzis wrote:
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.
With OpenStack I believe their deployment tool manages the config of
the entire host, so installing the libvirt-daemon-selinux package
ought to be reasonably straightforward for them.
I worry about KubeVirt though. IIUC in their deployment, the hosts
in use are all provisioned by OpenShift upfront & when KubeVirt is
deployed, the only pieces they're deploying live inside the host.
IOW, it seems like libvirt-daemon-selinux would have to be provided
ahead of time by OpenShift if it is to be used, and I'm not sure
if that's a practical requirement.
I think we need to get explicit confirmation from KubeVirt that
a requirement to installing RPMs directly on the host is going
to be acceptable.
I'm afraid that's not going to fly for KubeVirt.
Adding Roman and Vladik so they can provide more information.
For context, the discussion is about shipping the SELinux policy
for libvirt as part of a sub-package of libvirt instead of the main
selinux-policy package.
Reading again, I realize Vit links to a URL above that shows
virt-handler includes a custom selinux policy.
How does that get deployed, and can the libvirt-daemon-selinux
stuff be deployed in the same way ?
Based on a quick look at virt-handler it seems like the policy is
installed by installPolicy in cmd/virt-handler/virt-handler.go, which
just calls "semodule -i".
Shipping the policy is much more straight-forward in this case, since
it's in "cil" format, which means it does not need to be compiled before
installation.
I expect that it would be easier to include virt-daemon-selinux as a
dependency, instead of managing the virt policy.
Vit
Regards,
Daniel
