[libvirt] [ovs-dev] [PATCH v2 2/2] netdev-dpdk: Support user-defined socket attribs

[Daniel P. Berrange]

On Tue, May 31, 2016 at 10:59:18AM -0700, Ansis Atteka wrote:
> On 31 May 2016 at 09:36, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
> > > On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
> > > <christian.ehrhardt at canonical.com> wrote:
> > > > On Tue, May 24, 2016 at 4:10 PM, Aaron Conole <aconole at redhat.com>
> > wrote:
> > > >
> > > >> Daniele Di Proietto <diproiettod at vmware.com> writes:
> > > >>
> > > >> > Hi Aaron,
> > > >> >
> > > >> > I'm still a little bit nervous about calling chown on a (partially)
> > > >> > user controlled file name.
> > > >>
> > > >> I agree, that always seems scary.
> > > >>
> > > >> > Before moving forward I wanted to discuss a couple of other options:
> > > >> >
> > > >> > * Ansis (in CC) suggested using -runas parameter in qemu.  This way
> > > >> > qemu can open the socket as root and drop privileges before starting
> > > >> > guest execution.
> > > >>
> > > >> I'm not sure how to do this with libvirt, or via the OpenStack Neutron
> > > >> plugin.  I also don't know if it would be an acceptable workaround for
> > > >> users.  Additionally, I recall there being something of a "don't even
> > > >> know if this works" around it.  Maybe Christian or Ansis (both in CC)
> > > >> can expound on it.
> > > >>
> > >
> > > Cross-posting to libvirt mailing list to hear opinion from libvirt
> > developers.
> > >
> > > In short - the problem is that libvirtd process starts qemu process
> > > under non-root user. Since qemu starts under non-root process, then
> > > qemu can't connect to DPDK unix domain sockets created by ovs-vswitcd
> > > process that runs under "root". There are two solutions to this
> > > problem:
> > > 1. let ovs-vswitchd process to chown its socket from "root" to
> > > "libvirt" group and/or user (this is what Aarons patch proposes)
> > > 2. make libvirtd process to start qemu process under "root" but then
> > > let qemu to downgrade via "-run-as" flag after qemu has opened the
> > > Unix Domain socket.
> > >
> > > Regarding solution #2. I think the necessary changes roughly would be to:
> > > 1. invoke virCommandAddArgPair(cmd, "-runas", "libvirt") before
> > > starting qemu process; AND
> > > 2. revert virCommandSetUID() that automatically downgrades user from
> > > "root" to "libvirt" even before qemu starts.
> > > I would like to hear feasibility of such solution from libvirt
> > > developers? Or maybe there is even a better solution that I am
> > > missing?
> >
> > That's not going to happen.  Libvirt consider QEMU to be untrustworthy
> > in general and so apply multiple techniques to confine QEMU before it is
> > exec'd. This include dropping to non-0 uid/gid, applying apparmour/selinux
> > policies, putting it in restricted cgroups, and potentially more in the
> > future such as putting it in custom namespaces. We've no desire to use
> > qemu's -runas, as that means we're trusting QEMU to actually drop
> > privileges
> > as it claims to.
> >
> 
> Thanks for reply, Daniel! Yes, with -run-as flag it would be left at qemu's
> discretion to give up 'root' privileges and I understand you that it may
> not fit into security model chosen by libvirt.
> 
> 
> > Libvirt's model is that libvirt will setup policies to allow QEMU access
> > to the specific resources that it needs. so eg libvirt will chown the
> > disk images associated with the VM to give it access.
> >
> > I'm missing history of this thread, but IIUC, the issue here is access
> > to the UNIX domain socket associated with the vhost-user network backend
> > for QEMU. If so, then I think it is a case where libvirt should be setting
> > ownershup on that socket before starting QEMU, in order to grant access.
> > This of course assumes there is a separate UNIX domain socket per VM
> > that is launched.
> >
> 
> If the current libvirt security model is that libvirt is already
> chown()'ing resources needed by qemu, then perhaps vhost user socket may be
> another thing that libvirt needs to chown()? Or do you think that it would
> be better for libvirt to tell the user to which Open vSwitch needs to chown
> the socket (via the ovs-vsctl call in
> libvirt/src/util/virnetdevopenvswitch.c)?
> 
> Also, did I understand it correctly that libvirt also changes SELinux
> context for resources that qemu would be consuming so that qemu would be
> confined by additional Mandatory Access Control layer? If so, then I think
> the current libvirt security model suggests that chown()'ing and
> chcon()'ing should happen from libvirt and should not use Open vSwitch as a
> proxy to do that, because otherwise Open vSwitch SELinux policy would need
> to be loosened up to do such things.

Yes, I think libvirt should be in charge of granting access, not openvswitch,
since only libvirt has the world view of what the guest is supposed to have
access to.

> Also, what got me concerned is that Open vSwitch already has a Mandatory
> Access Control enforced under RHEL and Fedora distributions. For example,
> if libvirt changes SELinux context for files and sockets created by Open
> vSwitch then I am not sure how Open vSwitch would be able to cleanup them
> without getting permission denied errors. I will try this out on Fedora to
> see if my concern is justified.

It is entirely likely that we will need to make SELinux policy additions
to allow integration between svirt & openvswitch. I'd be surprised if it
worked as-is without triggering AVCs.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|