Hello all, tl;dr, can you point me to the point in the libvirt repo where it's trying to change a tap-device's SELinux label? I am trying to create a tap device with libvirt on a super-privileged container, and then use it on another, unprivileged container with libvirt. User wise, I know I need the super-privileged container to open the tap device with the user of the unprivileged one - that I already did and it's not the issue. But I have a problem when I open the tap device in the non-privileged container: the tap device currently has the spc_t label since the tun_socket inherited the selinux context from the super-privileged container who creates it. then libvirt is trying to change the SELinux labels, and since it's not privileged then it fails. But I didn't find where and how libvirt is trying to change the tap device's label. Can you point me to that specific code on libvirt? Ram Lavi Senior Software Engineer Red Hat Israel <https://www.redhat.com/> Yerushalaim Road 34, Ra'anana ralavi@redhat.com IM: ralavi @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com/>
On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote:> Hello all, > > tl;dr, can you point me to the point in the libvirt repo where it's trying > to change a tap-device's SELinux label? > > I am trying to create a tap device with libvirt on a > super-privileged container, and then use it on another, > unprivileged container with libvirt. > User wise, I know I need the super-privileged container to open the tap > device with the user of the unprivileged one - that I already did and it's > not the issue. > But I have a problem when I open the tap device in the > non-privileged container: the tap device currently has the spc_t label > since the tun_socket inherited the selinux context from the > super-privileged container who creates it. then libvirt is trying to change > the SELinux labels, and since it's not privileged then it fails. > But I didn't find where and how libvirt is trying to change the tap > device's label. > > Can you point me to that specific code on libvirt?If the SELinux policy that libvirtd is running under prevents it from re-labelling, then TAP devices label failure is just going to be one out of 100's of labelling failures. Either the SELinux policy needs to be changed to allow libvirtd to relabel stuff in the normal manner, or you will have to turn off SELinux support in libvirtd. in /etc/libvirt/qemu.conf via the param security_driver = "none". If you turn off SELinux in libvirt, then you no longer have separation of QEMU processes which may be a security flaw depending on your deplyoment scenario. 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 :|
On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <berrange@redhat.com> wrote:> On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote: > > Hello all, > > > > tl;dr, can you point me to the point in the libvirt repo where it's > trying > > to change a tap-device's SELinux label? > > > > I am trying to create a tap device with libvirt on a > > super-privileged container, and then use it on another, > > unprivileged container with libvirt. > > User wise, I know I need the super-privileged container to open the tap > > device with the user of the unprivileged one - that I already did and > it's > > not the issue. > > But I have a problem when I open the tap device in the > > non-privileged container: the tap device currently has the spc_t label > > since the tun_socket inherited the selinux context from the > > super-privileged container who creates it. then libvirt is trying to > change > > the SELinux labels, and since it's not privileged then it fails. > > But I didn't find where and how libvirt is trying to change the tap > > device's label. > > > > Can you point me to that specific code on libvirt? > > If the SELinux policy that libvirtd is running under prevents it from > re-labelling, then TAP devices label failure is just going to be one > out of 100's of labelling failures. >IIUC normally libvirtd would use devices created by itself, so there shouldn't be relabeling failures, right?> > Either the SELinux policy needs to be changed to allow libvirtd to > relabel stuff in the normal manner, or you will have to turn off > SELinux support in libvirtd. in /etc/libvirt/qemu.conf via the > param security_driver = "none". If you turn off SELinux in > libvirt, then you no longer have separation of QEMU processes > which may be a security flaw depending on your deplyoment > scenario. >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. 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. 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): https://github.com/kubevirt/kubevirt/pull/3290> > 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 :| > >