From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAaOd-0007Fj-6X for qemu-devel@nongnu.org; Wed, 08 Jun 2016 06:07:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAaOZ-0005du-3f for qemu-devel@nongnu.org; Wed, 08 Jun 2016 06:07:35 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:53899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAaOY-0005dd-Ry for qemu-devel@nongnu.org; Wed, 08 Jun 2016 06:07:31 -0400 Date: Wed, 8 Jun 2016 06:07:29 -0400 (EDT) From: Amnon Ilan Message-ID: <1277078136.58487083.1465380449805.JavaMail.zimbra@redhat.com> In-Reply-To: <297e40a1-9df0-cd85-68a1-b4ef5479f8bf@redhat.com> References: <1464712247-11655-1-git-send-email-wexu@redhat.com> <20160531164448.GE21628@redhat.com> <574F0A7B.5030401@redhat.com> <01045d4a-f03d-9f0d-deeb-4927446bb894@redhat.com> <20160602082904.GD9481@redhat.com> <297e40a1-9df0-cd85-68a1-b4ef5479f8bf@redhat.com> 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: Michal Privoznik , Flavio Leitner Cc: "Daniel P. Berrange" , qemu-devel@nongnu.org, amit shah , jasowang@redhat.com, Wei Xu , armbru@redhat.com ----- Original Message ----- > From: "Michal Privoznik" > To: "Daniel P. Berrange" > Cc: qemu-devel@nongnu.org, "amit shah" , jasowang@r= edhat.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' op= en 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 wrot= e: > >>>> 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 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 merel= y > >>>>> 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 sock= et > >>>> - 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 th= at > >>>> 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 shou= ld > >>> 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= : > >> > >> > >> > >> > >> > >> > >> > >> 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:6c,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 need th= is > >> 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 qem= u > >> 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). > >=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 directo= ry > > for the sockets. We certainly do not want to allow QEMU to create socke= ts > > 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 vhos= t > > 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 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= ? Flavio, do you know? If not, we are good as it is today with /var/lib/libvirt/qemu, right? Thanks, Amnon >=20 > Michal >=20 >=20