[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/4] Add access control support to qemu-bridge-h
Daniel P. Berrange
Re: [Qemu-devel] [PATCH 2/4] Add access control support to qemu-bridge-helper
Thu, 5 Nov 2009 15:06:57 +0000
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
> that this is the only functionality we expose.
> This is not good enough though. An administrator is likely to want to
> 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
> 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
> policies via the file system.
> If we fail to include an acl file, we are silent about it making this
> 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
|: 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 :|