qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH qemu-kvm] Add raw(af_packet) network backend


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu
Date: Wed, 27 Jan 2010 08:14:25 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 01/27/2010 12:52 AM, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Anthony Liguori wrote:
The raw backend can be attached to a physical device
This is equivalent to bridging with tun/tap except that it has the
unexpected behaviour of unreliable host/guest networking (which is not
universally consistent across platforms either).  This is not a mode we
want to encourage users to use.
It's not the most common scenario, but I've seen systems (I remember
one on s/390 with z/VM) where you really want to isolate the guest
network as much as possible from the host network. Besides PCI
passthrough, giving the host device to a guest using a raw socket
is the next best approximation of that.

But if you care about isolation, it's the worst possible thing to do. If a guest breaks into qemu, it's one bind() away from accessing any other guests network.

Using a bridge with a single interface on it is much better from an isolation perspective.

                               In general, what I would like to see for
this is something more user friendly that dealt specifically with this
use-case.  Although honestly, given the recent security concerns around
raw sockets, I'm very concerned about supporting raw sockets in qemu at all.

Essentially, you get worse security doing vhost-net + raw + VF then with
PCI passthrough + VF because at least in the later case you can run qemu
without privileges.  CAP_NET_RAW is a very big privilege.
It can be contained to a large degree with network namespaces. When you
run qemu in its own namespace and add the VF to that, CAP_NET_RAW
should ideally have no effect on other parts of the system (except
bugs in the namespace implementation).

That's a pretty big hammer to hit this problem with. QEMU should not require CAP_NET_RAW and so far has been able to avoid it quite successfully. So far, I haven't heard a compelling reason that to use raw other than bridging can be complicated to setup.

If we had the equivalent of a raw socket that could be bound to a socket and then "locked" such that it could be safely handed to a non-privileged process, then it would be a different story.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]