On 02.06.2016 10:29, Daniel P. Berrange wrote: > On Thu, Jun 02, 2016 at 09:41:56AM +0200, Michal Privoznik wrote: >> On 01.06.2016 18:16, Wei Xu wrote: >>> On 2016年06月01日 00:44, Daniel P. Berrange wrote: >>>> On Wed, Jun 01, 2016 at 12:30:44AM +0800, w...@redhat.com wrote: >>>>> From: Wei Xu <w...@redhat.com> >>>>> >>>>> Recently I'm working on a fd passing issue, selinux forbids qemu to >>>>> create a unix socket for a chardev when managing VMs with libvirt, >>>>> because qemu don't have sufficient permissions in this case, and >>>>> proposal from libvirt team is opening the 'fd' in libvirt and merely >>>>> passing it to qemu. >>>> >>>> This sounds like a bug in libvirt, or selinux, or a mistaken >>>> configuration >>>> of the guest. It is entirely possible for QEMU to create a unix socket >>>> - not >>>> least because that is exactly what QEMU uses for its QMP monitor backend. >>>> Looking at your example command line, I think the issue is simply that >>>> you >>>> should be putting the sockets in a different location. ie at >>>> /var/lib/libvirt/qemu/$guest-vhost-user1.sock where QEMU has >>>> permission to >>>> create sockets already. >>> ah.. adjusting permission or file location can solve this problem, i'm >>> guessing maybe this is a more security concern, the socket is used as a >>> network interface for a vm, similar as the qcow image file, thus should >>> prevent it to be arbitrarily accessed. >>> >>> Michael, do you have any comment on this? >> >> I haven't seen the patches. But in libvirt we allow users to create a >> vhostuser interface and even specify where the socket should be placed: >> >> <interface type='vhostuser'> >> <mac address='52:54:00:ee:96:6c'/> >> <source type='unix' path='/tmp/vhost1.sock' mode='server'/> >> <model type='virtio'/> >> </interface> >> >> The following cmd line is generated by libvirt then: >> >> -chardev socket,id=charnet1,path=/tmp/vhost1.sock,server \ >> -netdev type=vhost-user,id=hostnet1,chardev=charnet1 \ >> -device >> virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:ee:96:6c,bus=pci.0,\ >> >> Now, if we accept only /var/run/openvwitch path in >> /interface/source/@path (or whatever path to OVS is), we don't need this >> and have users manually label the dir (unless already labeled). But >> since we accept just any path in there, we should make sure that qemu is >> then able to create the socket. One possible fix would be to allow qemu >> create sockets just anywhere in the system. This, however, brings huge >> security risks and it's not acceptable IMO. The other option would be >> that libvirt would create the socket, and pass its FD to qemu (since >> libvirt already is allowed to create sockets anywhere). > > There are plenty of other places where we allow arbitrary paths in the > XML, but which have restrictions imposed by the security drivers. Not > least the <channel> devices which have the exact same scenario as this > network device, and require use of /var/lib/libvirt/qemu as the directory > for the sockets. We certainly do not want to allow QEMU to create sockets > anywhere. > > I don't think we want to grant QEMU svirtt permission to create sockets > in the /var/run/openvswitch directory either really.IMHO, users of vhost > user should really be using /var/lib/libvirt/qemu, as is used for all > other UNIX sockets we create wrt other devices.
Okay. I can live with that; but in that case we should document it somewhere, that we guarantee only paths under /var/lib/libvirt/ to be accessible and for the rest we do our best but maybe require sys admin intervention (e.g. to label the whole tree for a non-standard location). Michal
