<div dir="ltr"><div dir="ltr"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:RedHatText,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small;font-weight:normal;color:rgb(34,34,34)">On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:</span><br></p></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote:<br>
> Hello all,<br>
> <br>
> tl;dr, can you point me to the point in the libvirt repo where it's trying<br>
> to change a tap-device's SELinux label?<br>
> <br>
> I am trying to create a tap device with libvirt on a<br>
> super-privileged container, and then use it on another,<br>
> unprivileged container with libvirt.<br>
> User wise, I know I need the super-privileged container to open the tap<br>
> device with the user of the unprivileged one - that I already did and it's<br>
> not the issue.<br>
> But I have a problem when I open the tap device in the<br>
> non-privileged container: the tap device currently has the spc_t label<br>
> since the tun_socket inherited the selinux context from the<br>
> super-privileged container who creates it. then libvirt is trying to change<br>
> the SELinux labels, and since it's not privileged then it fails.<br>
> But I didn't find where and how libvirt is trying to change the tap<br>
> device's label.<br>
> <br>
> Can you point me to that specific code on libvirt?<br>
<br>
If the SELinux policy that libvirtd is running under prevents it from<br>
re-labelling, then TAP devices label failure is just going to be one<br>
out of 100's of labelling failures.<br></blockquote><div>IIUC normally libvirtd would use devices created by itself, so there shouldn't be relabeling failures, right? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Either the SELinux policy needs to be changed to allow libvirtd to<br>
relabel stuff in the normal manner, or you will have to turn off<br>
SELinux  support in libvirtd. in /etc/libvirt/qemu.conf via the<br>
param security_driver = "none".  If you turn off SELinux in<br>
libvirt, then you no longer have separation of QEMU processes<br>
which may be a security flaw depending on your deplyoment<br>
scenario.<br></blockquote><div>turning SELinux in libvirtd off or allowing libvirt to relabel are tempting options but it is not an option I'm afraid due to security concerns.</div><div>Our plan (or at least this particular effort) is to try to relabel the tun-socket after created in the super-privileged container to be the same one as the one used in the unprivileged one, then it won't  have an issue consuming it.</div><div><br></div><div>btw the change I (or rather Migule's my teammate) made is in this PR, where I want to add a tap device in virt-handler (i.e. the super privileged container) to be further uses in virt-launcher (i.e. the non-privileged container): <a href="https://github.com/kubevirt/kubevirt/pull/3290" target="_blank">https://github.com/kubevirt/kubevirt/pull/3290</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Regards,<br>
Daniel<br>
-- <br>
|: <a href="https://berrange.com" rel="noreferrer" target="_blank">https://berrange.com</a>      -o-    <a href="https://www.flickr.com/photos/dberrange" rel="noreferrer" target="_blank">https://www.flickr.com/photos/dberrange</a> :|<br>
|: <a href="https://libvirt.org" rel="noreferrer" target="_blank">https://libvirt.org</a>         -o-            <a href="https://fstop138.berrange.com" rel="noreferrer" target="_blank">https://fstop138.berrange.com</a> :|<br>
|: <a href="https://entangle-photo.org" rel="noreferrer" target="_blank">https://entangle-photo.org</a>    -o-    <a href="https://www.instagram.com/dberrange" rel="noreferrer" target="_blank">https://www.instagram.com/dberrange</a> :|<br>
<br>
</blockquote></div></div>