[ovs-dev] [PATCH v2 0/2] vhost-user: Add the ability to control ownership/permissions

[Ansis Atteka]

On 20 May 2016 at 13:32, Aaron Conole <aconole at redhat.com> wrote:

> Currently, when using Open vSwitch with DPDK and qemu guests, the
> recommended
> method for joining the guests is via the dpdkvhostuser interface. This
> interface uses Unix Domain sockets to communicate. When these sockets are
> created, they inherit the permissions and ownership from the vswitchd
> process.
> This can lead to an undesirable state where the QEMU process cannot use the
> socket file until manual intervention is performed (via `chown` and/or
> `chmod`
> calls).
>

Hi Aaron,

Could you explain:
1. who would be setting the owner via this newly introduced OVSDB interface?
2. who would be starting the QEMU process for use-cases you are trying to
solve here?

I am asking this because in another thread [
http://openvswitch.org/pipermail/dev/2016-June/071935.html] I had
discussion with Libvirt folks and they explained to me that under their
current security model they think it should be Libvirt doing the actual
chown() calls and that they would prefer not use Open vSwitch as a proxy to
do it for them. This is at least what they apparently have been doing all
this time to lock down privileges for QEMU processes.

Some food for thoughts:
1. What, if in future Libvirt will chown() the DPDK sockets directly and
override the value set in OVSDB (assuming QEMU is started by libvirt, but
ovs-vsctl is invoked by some other process)?
2. What about Mandatory Access Control security context (the one you see in
`ls -Z <file>` output on RHEL-type distributions)? Do you plan to set it as
well in the future from ovs-vswitchd? MAC is another security layer that
Libvirt uses to confine QEMU.
3. Also this patch kinda conflicts with --user flag because then ovs user
would have to be put under "qemu" group to be able to chown sockets to
"qemu" user. This reexposes OVS to untrusted resources owned by qemu user.
Anyway this flag does not work with DPDK anyway and I think we may want to
deprecate it.

Also what you have may be completely fine:
1. as a short term solution for Libvirt if it currently does not chown()
DPDK sockets; OR
2. if you are targeting this feature for hypervisors that are not using
Libvirt and have completely different security model.

Thanks,
Ansis