From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N63ve-0005iF-Tp for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:07:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N63vW-0005Wo-1u for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:07:10 -0500 Received: from [199.232.76.173] (port=53400 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N63vV-0005WC-Rp for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:07:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26287) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N63vS-0003vo-V6 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 10:07:04 -0500 Date: Thu, 5 Nov 2009 15:06:57 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 2/4] Add access control support to qemu-bridge-helper Message-ID: <20091105150657.GE689@redhat.com> References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <1257294485-27015-3-git-send-email-aliguori@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1257294485-27015-3-git-send-email-aliguori@us.ibm.com> Reply-To: "Daniel P. Berrange" 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 , Juan Quintela , qemu-devel@nongnu.org On Tue, Nov 03, 2009 at 06:28:03PM -0600, Anthony Liguori wrote: > We go to great lengths to restrict ourselves to just cap_net_admin as an OS > enforced security mechanism. However, we further restrict what we allow users > to do to simply adding a tap device to a bridge interface by virtue of the fact > that this is the only functionality we expose. > > This is not good enough though. An administrator is likely to want to restrict > the bridges that an unprivileged user can access, in particular, to restrict > an unprivileged user from putting a guest on what should be isolated networks. > > This patch implements a ACL mechanism that is enforced by qemu-bridge-helper. > The ACLs are fairly simple whitelist/blacklist mechanisms with a wildcard of > 'all'. > > An interesting feature of this ACL mechanism is that you can include external > ACL files. The main reason to support this is so that you can set different > file system permissions on those external ACL files. This allows an > administrator to implement rather sophisicated ACL policies based on user/group > policies via the file system. > > If we fail to include an acl file, we are silent about it making this mechanism > work pretty seamlessly. As an example: > > /etc/qemu/bridge.conf root:qemu 0640 > > deny all > allow br0 > include /etc/qemu/alice.conf > include /etc/qemu/bob.conf > > /etc/qemu/alice.conf root:alice 0640 > allow br1 > > /etc/qemu/bob.conf root:bob 0640 > allow br2 > > This ACL pattern allows any user in the qemu group to get a tap device > connected to br0 (which is bridged to the physical network). > > Users in the alice group can additionally get a tap device connected to br1. > This allows br1 to act as a private bridge for the alice group. > > Users in the bob group can additionally get a tap device connected to br2. > This allows br2 to act as a private bridge for the bob group. > > Under no circumstance can the bob group get access to br1 or can the alice > group get access to br2. If we're going to define an ACL file for this, then I'd like us to try and get a file format that is suitable for all possible ACL needs in QEMU. In particular to allow coverage of VNC server ACLs which I previously did a proof of concept for http://article.gmane.org/gmane.comp.emulators.qemu/38173 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|