From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu Date: Wed, 27 Jan 2010 11:36:31 -0600 Message-ID: <4B60799F.80708@codemonkey.ws> References: <1264538423.24933.144.camel@w-sridhar.beaverton.ibm.com> <4B5F54E8.3080507@codemonkey.ws> <4B5F5594.6080006@codemonkey.ws> <20100127092451.GC3476@redhat.com> <4B60488F.5020506@codemonkey.ws> <20100127165909.GA13260@redhat.com> <4B6072E1.7030702@codemonkey.ws> <20100127172536.GD13260@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sridhar Samudrala , avi@redhat.com, markmc@redhat.com, ogerlitz@voltaire.com, kvm@vger.kernel.org, qemu-devel@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from mail-iw0-f186.google.com ([209.85.223.186]:60601 "EHLO mail-iw0-f186.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754591Ab0A0Rgg (ORCPT ); Wed, 27 Jan 2010 12:36:36 -0500 In-Reply-To: <20100127172536.GD13260@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Regards, Anthony Liguori > Security is probably a wrong > reason to use character devices: they are much more likely to have > security problems than standard interfaces. Ease of setup/compatibility > with tap would be a better reason. > > >> Regards, >> >> Anthony Liguori >> >> >>>> Regards, >>>> >>>> Anthony Liguori >>>> >>>>