----- Original Message ----- > From: "Aaron Conole" <[email protected]> > To: "Flavio Leitner" <[email protected]> > Cc: "Amnon Ilan" <[email protected]>, "Michal Privoznik" > <[email protected]>, "Daniel P. Berrange" > <[email protected]>, [email protected], "amit shah" > <[email protected]>, [email protected], "Wei Xu" > <[email protected]>, [email protected] > Sent: Thursday, June 9, 2016 12:48:57 AM > Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open > from outside for unix socket > > Flavio Leitner <[email protected]> writes: > > > Adding Aaron who is fixing exactly that on the OVS side. > > > > Aaron, please see the last question in the bottom of this email. > > > > On Wed, Jun 08, 2016 at 06:07:29AM -0400, Amnon Ilan wrote: > >> > >> > >> ----- Original Message ----- > >> > From: "Michal Privoznik" <[email protected]> > >> > To: "Daniel P. Berrange" <[email protected]> > >> > Cc: [email protected], "amit shah" <[email protected]>, > >> > [email protected], "Wei Xu" <[email protected]>, > >> > [email protected] > >> > Sent: Thursday, June 2, 2016 2:38:53 PM > >> > Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket > >> > 'fd' open from outside for unix socket > >> > > >> > 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, [email protected] wrote: > >> > >>>>> From: Wei Xu <[email protected]> > >> > >>>>> > >> > >>>>> 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). > >> > >> Does OVS has some limit for it's sockets to be only in > >> /var/run/openvswitch ? > > As of a recent commit, it can only be in /var/run/openvswitch or a > subdirectory therein (found in the openvswitch database). > > >> Flavio, do you know? > >> If not, we are good as it is today with /var/lib/libvirt/qemu, right? > > Probably not. There are other issues as well. From a DAC perspective > (so forgetting selinux at the moment), qemu and ovs run as different > users. This will mean that when ovs creates the unix domain socket > file, qemu will not be allowed to actually open it properly. I have a > commit I'm trying to get upstream for that particular issue (see > bz:1281911 and upstream list discussion: > http://openvswitch.org/pipermail/dev/2016-May/071453.html > and > http://openvswitch.org/pipermail/dev/2016-June/071978.html) > > Ansis is (I think) attacking this from the selinux/MAC side. It would > be great to hear from users, libvirt folks, or anyone else in that > thread to help push it to a conclusion one way or another (even if the > approach that I've proposed is crap and wrong - then say it there :).
Based on Aaron's comments, I think we should let libvirt open the socket and pass the file descriptor to Qemu. Thanks, Amnon > > Hope this helps, > -Aaron >
