Re: [Qemu-devel] [RFC Patch 0/3] Accept passed in socket 'fd' open from outside for unix socket

[Amnon Ilan]

----- Original Message -----
> From: "Aaron Conole" <address@hidden>
> To: "Flavio Leitner" <address@hidden>
> Cc: "Amnon Ilan" <address@hidden>, "Michal Privoznik" <address@hidden>, 
> "Daniel P. Berrange"
> <address@hidden>, address@hidden, "amit shah" <address@hidden>, 
> address@hidden, "Wei Xu"
> <address@hidden>, address@hidden
> 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 <address@hidden> 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" <address@hidden>
> >> > To: "Daniel P. Berrange" <address@hidden>
> >> > Cc: address@hidden, "amit shah" <address@hidden>,
> >> > address@hidden, "Wei Xu" <address@hidden>,
> >> > address@hidden
> >> > 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, address@hidden wrote:
> >> > >>>>> From: Wei Xu <address@hidden>
> >> > >>>>>
> >> > >>>>> 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
>