<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" 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 6:03 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com">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 04:02:17PM +0300, Ram Lavi wrote:<br>
> On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
> wrote:<br>
> <br>
> > 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<br>
> > 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<br>
> > 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<br>
> > 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>
> ><br>
> IIUC normally libvirtd would use devices created by itself, so there<br>
> shouldn't be relabeling failures, right?<br>
<br>
Whether or not there are relabeling failures is determined by what<br>
SELinux policy libvirtd is running under.<br>
<br>
> ><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>
> ><br>
> turning SELinux in libvirtd off or allowing libvirt to relabel are tempting<br>
> options but it is not an option I'm afraid due to security concerns.<br>
> Our plan (or at least this particular effort) is to try to relabel the<br>
> tun-socket after created in the super-privileged container to be the same<br>
> one as the one used in the unprivileged one, then it won't  have an issue<br>
> consuming it.<br>
> <br>
> btw the change I (or rather Migule's my teammate) made is in this PR, where<br>
> I want to add a tap device in virt-handler (i.e. the super privileged<br>
> container) to be further uses in virt-launcher (i.e. the non-privileged<br>
> container): <a href="https://github.com/kubevirt/kubevirt/pull/3290" rel="noreferrer" target="_blank">https://github.com/kubevirt/kubevirt/pull/3290</a><br>
<br>
In normal host OS deployment,  libvirtd runs under virtd_t, and when<br>
it spawns QEMU, it will relabel files to svirt_image_t:s0:$MCS, and<br>
spawn QEMU as svirt_t:s0:$MCS.<br>
<br>
My understanding is what in kubevirt, things work differently. Docker<br>
(or podman), launch the container as  container_t:s0:$MCS.  libvirtd<br>
*and* QEMU thus both run as container_t:s0:$MCS. ie All the labelling<br>
is setup when the container is launched and libvirtd should not do<br>
anything.<br>
<br>
So I'm really not sure why you have libvirtd configured to do relabelling<br>
at all ?  I'd be expecting it to have security_driver=none in the qemu.conf<br>
file so that libvirtd doesn't do anything.<br></blockquote><div>I checked the dumpxml of the virt-launcher pod (that runs the qemu in kubevirt) - it has dynamic policy. </div><div></div><div></div><div class="markdown-here-wrapper" style=""><pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+107:+107</label>
    <imagelabel>+107:+107</imagelabel>
  </seclabel>
</code></pre><div title="MDH:PGRpdj5gYGA8L2Rpdj48ZGl2PiZuYnNwOyAmbHQ7c2VjbGFiZWwgdHlwZT0nZHluYW1pYycgbW9k
ZWw9J2RhYycgcmVsYWJlbD0neWVzJyZndDs8YnI+Jm5ic3A7ICZuYnNwOyAmbHQ7bGFiZWwmZ3Q7
KzEwNzorMTA3Jmx0Oy9sYWJlbCZndDs8YnI+Jm5ic3A7ICZuYnNwOyAmbHQ7PHNwYW4gemV1bTRj
ND0iUFJfMjFfMCIgZGF0YS1kZG53YWI9IlBSXzIxXzAiIGFyaWEtaW52YWxpZD0ic3BlbGxpbmci
IGNsYXNzPSJMSSBuZyI+aW1hZ2VsYWJlbDwvc3Bhbj4mZ3Q7KzEwNzorMTA3Jmx0Oy88c3BhbiB6
ZXVtNGM0PSJQUl8yMl8wIiBkYXRhLWRkbndhYj0iUFJfMjJfMCIgYXJpYS1pbnZhbGlkPSJzcGVs
bGluZyIgY2xhc3M9IkxJIG5nIj5pbWFnZWxhYmVsPC9zcGFuPiZndDs8YnI+Jm5ic3A7ICZsdDsv
c2VjbGFiZWwmZ3Q7PGJyPjwvZGl2PjxkaXY+YGBgPC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div><div></div><div></div><div>Are you saying this a wrong configuration for a kubevirt vmi?  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If libvirtd is doing relabelling, I'm not sure how it works for anything,<br>
let alone tap devices. <br></blockquote><div>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).</div><div>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.</div><div>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.</div><div>Is this were libvirt does the relabeling <a href="https://github.com/libvirt/libvirt/blob/e71e13488dc1aa65456e54a4b41bc925821b4263/src/security/security_selinux.c#L1256">https://github.com/libvirt/libvirt/blob/e71e13488dc1aa65456e54a4b41bc925821b4263/src/security/security_selinux.c#L1256</a>? </div><div><br></div><div>btw the error we get is (from audit)</div><div><div class="markdown-here-wrapper" style=""><pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">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
</code></pre><div title="MDH:YGBgPGJyIGNsYXNzPSJnbWFpbC1BcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48c3BhbiBzdHls
ZT0iY29sb3I6IHJnYigzMiwgMzMsIDM2KTsgZm9udC1mYW1pbHk6IFJvYm90bywgc2Fucy1zZXJp
ZjsgZm9udC1zaXplOiAxNHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IGJhY2tncm91bmQtY29s
b3I6IHJnYigyNDgsIDI0OSwgMjUwKTsiPnR5cGU9QVZDIG1zZz1hdWRpdCgxNTg2OTU2NTUyLjI2
NTo1MTMpOiBhdmM6IGRlbmllZCB7IHJlbGFiZWxmcm9tIH0gZm9yIHBpZD0yNzQyMyBjb21tPSJs
aWJ2aXJ0ZCIgc2NvbnRleHQ9c3lzdGVtX3U6c3lzdGVtX3I6Y29udGFpbmVyX3Q6czA6YzE0Myxj
NTgyIHRjb250ZXh0PXN5c3RlbV91OnN5c3RlbV9yOnNwY190OnMwIHRjbGFzcz10dW5fc29ja2V0
IHBlcm1pc3NpdmU9MDwvc3Bhbj48YnI+YGBg" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></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>