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.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
