From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N7WLN-0003z5-2w for qemu-devel@nongnu.org; Mon, 09 Nov 2009 10:39:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N7WLI-0003sz-6V for qemu-devel@nongnu.org; Mon, 09 Nov 2009 10:39:48 -0500 Received: from [199.232.76.173] (port=41925 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N7WLI-0003sp-3X for qemu-devel@nongnu.org; Mon, 09 Nov 2009 10:39:44 -0500 Received: from mail2.shareable.org ([80.68.89.115]:38202) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N7WLH-0002PL-Fp for qemu-devel@nongnu.org; Mon, 09 Nov 2009 10:39:43 -0500 Date: Mon, 9 Nov 2009 15:39:33 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 4/4] Add support for -net bridge Message-ID: <20091109153933.GA1073@shareable.org> References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <1257294485-27015-5-git-send-email-aliguori@us.ibm.com> <1257614967.30774.424.camel@macbook.infradead.org> <4AF5F0A2.8050309@codemonkey.ws> <4AF680FD.5050101@redhat.com> <4AF82524.8080805@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF82524.8080805@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Arnd Bergmann , Dustin Kirkland , Michael Tsirkin , qemu-devel@nongnu.org, Juan Quintela , Avi Kivity , David Woodhouse Anthony Liguori wrote: > Let's not kid ourselves, no matter what we do we're giving a user > elevated privileges. Even with NAT, if the host can access the NAT'ed > network, then you can run a privileged service (like NFS) in that > network. I don't see how outgoing NAT (SNAT), where the guest can make _outgoing_ connections to the network, allows the guest to run a privileged service accessible to the network. Sure, the guest can run an NFS server, but it means nothing to the outside - it's on the guest's own private little network. Same as Slirp. The guest cannot even make an outgoing request which appears to come from an privileged port - if the SNAT rule has the appropriate options to force the port into an unprivileged range. For the guest's NFS server to be visible to the network requires incoming NAT (DNAT) on the host, often called "port forwarding". But that is done by explicit administration; if you can do that, you can run a privileged service on the host anyway. > I think the best we can do is provide a tool that allows an > administrator to grant users additional privileges in the tiniest > increments possible. Putting people in wheel just so they can do > virtualization is too much. > > I don't see having an fscap-based helper as creating policy. I see it > as adding a mechanism for administrators to create policy. I agree with both of these. -- Jamie