On Thu, Jul 16, 2020 at 11:22:26AM +0300, Ram Lavi wrote:
> On Tue, Jul 14, 2020 at 6:03 PM Daniel P. Berrangé <berra...@redhat.com>
> wrote:
> 
> I checked the dumpxml of the virt-launcher pod (that runs the qemu in
> kubevirt) - it has dynamic policy.
> 
>   <seclabel type='dynamic' model='dac' relabel='yes'>
>     <label>+107:+107</label>
>     <imagelabel>+107:+107</imagelabel>
>   </seclabel>
> 
> Are you saying this a wrong configuration for a kubevirt vmi?

No, this is exactly what I'm expecting and matches the behaviour I
mentioned in my previous mail, where SELinux is not enabled in libvirtd.

This setting is completely unrelated to SELinux. This seclabel is for the
"dac" model, aka Discretionary Access Control, aka plain old POSIX users
and groups. It is used when libvirtd runs as root, and then launches QEMU
as a separate "qemu:qemu" user:group pair.

If selinux / sVirt was in use you would see a separate <seclabel> with
model="selinux".

If you don't see that, then libvirtd is *not* doing any SELinux labelling
at all.

This makes me wonder how you hit the relabelling AVC ? It feels very much
like your custom work to deal with passing in TAP devices has mistakenly
changed something else and thus incorrectly turned on SELinux/sVirt in
libvirtd.

> > If libvirtd is doing relabelling, I'm not sure how it works for anything,
> > let alone tap devices.
> >
> I want to emphasize that in this current situation the reason we fail is
> that we are trying to give libvirt in a non-privileged pod (i.e.
> virt-launcher) a tap device that was created externally (by a privileged
> pod - virt-handler).
> I think the reason it works so far is that libvirt was using only devices
> which were self created so there was no issue to relabel.

I believe the reason it works historically is that libvirtd is not using
SELinux, per your <seclabel> config above, and so was not attempting
todo any relabelling in the first place.

> Our thought was that if we know how  libvirt is relabeling then we could
> also do it so that the externally created tap's label will match the
> virt-launcher's.

You almost certainly *will* need to relabel the tap device when passing
it from your privileged container into the unprivileged, but this is not
due to libvirtd. This is because podman is likely using a different
SELinux label for the two containers as they have different privilege
levels. The tap device needs to be given the SELinux label matching the
unprivileged container.

> Is this were libvirt does the relabeling
> https://github.com/libvirt/libvirt/blob/e71e13488dc1aa65456e54a4b41bc925821b4263/src/security/security_selinux.c#L1256
> ?

That's for setting contexts on files, for FDs you need to call
fsetfilecon_raw

> btw the error we get is (from audit)
> 
> type=AVC msg=audit(1586956552.265:513): avc: denied { relabelfrom }
> for pid=27423 comm="libvirtd"
> scontext=system_u:system_r:container_t:s0:c143,c582
> tcontext=system_u:system_r:spc_t:s0 tclass=tun_socket permissive=0

This just suggests libvirtd has been misconfigured in some way that causes
SELinux to become enabled again.

You need to do relabelling of the TAP device, but that isn't going to
avoid this AVC - it will just change what you see as the tcontext in
the AVC. You still need to fix the configuration of libvirtd I believe.

If you run 'virsh capabilities' in your container that is showing this
problem, I expect it will say:

    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
      <baselabel type='kvm'>system_u:system_r:svirt_t:s0</baselabel>
      <baselabel type='qemu'>system_u:system_r:svirt_tcg_t:s0</baselabel>
    </secmodel>


If you compare with the "virsh capabilities" from a correctly operating
existing KubeVirt install, then I expect selinux won't be reported at
all, which would match your <seclabel> example from earlier.


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 :|

Reply via email to