From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAufa-0004j6-Pg for qemu-devel@nongnu.org; Thu, 09 Jun 2016 03:46:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAufW-0005ly-6y for qemu-devel@nongnu.org; Thu, 09 Jun 2016 03:46:26 -0400 Received: from mx5-phx2.redhat.com ([209.132.183.37]:49015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAufV-0005lu-Up for qemu-devel@nongnu.org; Thu, 09 Jun 2016 03:46:22 -0400 Date: Thu, 9 Jun 2016 03:46:19 -0400 (EDT) From: Amnon Ilan Message-ID: <1964028176.58771956.1465458379625.JavaMail.zimbra@redhat.com> In-Reply-To: References: <1464712247-11655-1-git-send-email-wexu@redhat.com> <574F0A7B.5030401@redhat.com> <01045d4a-f03d-9f0d-deeb-4927446bb894@redhat.com> <20160602082904.GD9481@redhat.com> <297e40a1-9df0-cd85-68a1-b4ef5479f8bf@redhat.com> <1277078136.58487083.1465380449805.JavaMail.zimbra@redhat.com> <20160608212738.GH3073@plex> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aaron Conole , Michal Privoznik Cc: Flavio Leitner , "Daniel P. Berrange" , qemu-devel@nongnu.org, amit shah , jasowang@redhat.com, Wei Xu , armbru@redhat.com ----- Original Message ----- > From: "Aaron Conole" > To: "Flavio Leitner" > Cc: "Amnon Ilan" , "Michal Privoznik" , "Daniel P. Berrange" > , qemu-devel@nongnu.org, "amit shah" , jasowang@redhat.com, "Wei Xu" > , armbru@redhat.com > Sent: Thursday, June 9, 2016 12:48:57 AM > Subject: Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' op= en from outside for unix socket >=20 > Flavio Leitner writes: >=20 > > 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: > >>=20 > >>=20 > >> ----- Original Message ----- > >> > From: "Michal Privoznik" > >> > To: "Daniel P. Berrange" > >> > Cc: qemu-devel@nongnu.org, "amit shah" , > >> > jasowang@redhat.com, "Wei Xu" , > >> > armbru@redhat.com > >> > 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 > >> >=20 > >> > 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=E5=B9=B406=E6=9C=8801=E6=97=A5 00:44, Daniel P. Berrange= wrote: > >> > >>>> On Wed, Jun 01, 2016 at 12:30:44AM +0800, wexu@redhat.com wrote= : > >> > >>>>> From: Wei Xu > >> > >>>>> > >> > >>>>> Recently I'm working on a fd passing issue, selinux forbids qe= mu > >> > >>>>> to > >> > >>>>> create a unix socket for a chardev when managing VMs with libv= irt, > >> > >>>>> because qemu don't have sufficient permissions in this case, a= nd > >> > >>>>> 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 monito= r > >> > >>>> backend. > >> > >>>> Looking at your example command line, I think the issue is simp= ly > >> > >>>> 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 proble= m, > >> > >>> i'm > >> > >>> guessing maybe this is a more security concern, the socket is us= ed > >> > >>> 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 crea= te a > >> > >> vhostuser interface and even specify where the socket should be > >> > >> placed: > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> The following cmd line is generated by libvirt then: > >> > >> > >> > >> -chardev socket,id=3Dcharnet1,path=3D/tmp/vhost1.sock,server \ > >> > >> -netdev type=3Dvhost-user,id=3Dhostnet1,chardev=3Dcharnet1 \ > >> > >> -device > >> > >> virtio-net-pci,netdev=3Dhostnet1,id=3Dnet1,mac=3D52:54:00:ee:96:6= c,bus=3Dpci.0,\ > >> > >> > >> > >> Now, if we accept only /var/run/openvwitch path in > >> > >> /interface/source/@path (or whatever path to OVS is), we don't ne= ed > >> > >> this > >> > >> and have users manually label the dir (unless already labeled). B= ut > >> > >> 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 allo= w > >> > >> qemu > >> > >> create sockets just anywhere in the system. This, however, brings > >> > >> huge > >> > >> security risks and it's not acceptable IMO. The other option woul= d be > >> > >> that libvirt would create the socket, and pass its FD to qemu (si= nce > >> > >> libvirt already is allowed to create sockets anywhere). > >> > >=20 > >> > > 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 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. > >> > >=20 > >> > > 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. > >> >=20 > >> > 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 b= e > >> > accessible and for the rest we do our best but maybe require sys adm= in > >> > intervention (e.g. to label the whole tree for a non-standard locati= on). > >>=20 > >> Does OVS has some limit for it's sockets to be only in > >> /var/run/openvswitch ? >=20 > As of a recent commit, it can only be in /var/run/openvswitch or a > subdirectory therein (found in the openvswitch database). >=20 > >> Flavio, do you know? > >> If not, we are good as it is today with /var/lib/libvirt/qemu, right? >=20 > 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) >=20 > 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 an= d pass=20 the file descriptor to Qemu. Thanks, Amnon >=20 > Hope this helps, > -Aaron >=20