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

Sridhar Samudrala
2010-01-27T17:55:11Z

On Wed, 2010-01-27 at 11:36 -0600, Anthony Liguori wrote:
> On 01/27/2010 11:25 AM, Michael S. Tsirkin wrote:
> >> In this case, the full
> >> syntax would be:
> >>
> >> -net vepa,if=eth0
> >>
> >> or
> >>
> >> -net vepa,fd=N
> >>
> > I still hope it's extbridge, vepa is an acronym that will likely not be
> > known for 99% of users.
> >
>
> Oh sorry, I don't care about the name at all. If you prefer extbridge,
> I'm all for it :-)
>
> >> where N is a macvtap fd.
> >>
> >> For raw, I think there's a real problem wrt security. I think it's
> >> important that we support running qemu as a non-privileged user. In
> >> fact, this seems to be the mode libvirt is now preferring to operate in.
> >>
> >> I think we need to re-evaluate the use of any raw socket by qemu as it's
> >> very dangerous from a security perspective (assuming we cannot
> >> introduced a "locked" raw socket mode).
> >>
> > As was pointed out on netdev and elsewhere this seems to be what
> > namespaces/selinux are there for. Can qemu be run within a namespace and
> > if yes would that address your concerns?
>
> It's unclear to me what this would even involve. But really, we just
> want an interface to inject packets directly into a physical device.
> raw sockets give us that but it also gives us way more. Using network
> namespaces to restrict this is a bit convoluted. It seems to me that
> providing an interface that never gives us way more to start with is
> better overall from a security perspective.

I too think that we should not block raw backend in qemu just because of
security reasons. It should be perfectly fine to use raw backend in
scenarios where qemu can be run as a privileged process.

libvirt need not support raw backend until we figure out a secure way to
start qemu when passing raw fd. using network namespaces seems like a
good option.

Thanks
Sridhar