On Tue, 2012-07-03 at 12:05 -0400, rmarwah@linux.vnet.ibm.com wrote:
Quoting Jamie Strandboge <jamie@canonical.com>:
On Fri, 2012-06-29 at 14:08 -0400, rmarwah@linux.vnet.ibm.com wrote:
From: Richa Marwaha <rmarwah@linux.vnet.ibm.com>
This patch provides AppArmor policy updates for the QEMU bridge helper. The QEMU bridge helper is a SUID executable exec'd by QEMU that drops capabilities to CAP_NET_ADMIN and adds a tap device to a network bridge.
Signed-off-by: Richa Marwaha <rmarwah@linux.vnet.ibm.com> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com> --- examples/apparmor/libvirt-qemu | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 10cdd36..766a334 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -1,4 +1,4 @@ -# Last Modified: Mon Apr 5 15:11:27 2010 +# Last Modified: Fri Mar 9 14:43:22 2012
#include <abstractions/base> #include <abstractions/consoles> @@ -108,3 +108,22 @@ /bin/dash rmix, /bin/dd rmix, /bin/cat rmix, + + /usr/libexec/qemu-bridge-helper Cx, + # child profile for bridge helper process + profile /usr/libexec/qemu-bridge-helper { + #include <abstractions/base> + + capability setuid, + capability setgid, + capability setpcap, + capability net_admin, + + network inet stream, + + /dev/net/tun rw, + /etc/qemu/** r, + owner @{PROC}/*/status r, + + /usr/libexec/qemu-bridge-helper rmix, + }
Looking at the child profile itself, this seems fine.
However, the Cx transition makes it so that all libvirt-managed qemu processes are allowed to execute this setuid helper and I wonder if that is too much? Ie, a guest running under libvirt's NAT wouldn't need access to this helper at all. I wonder if it would be better to adjust virt-aa-helper to add this transition and child profile instead (the child profile could theoretically still be in apparmor/libvirt-qemu, but this is a bit messy)? Can we determine from the domain XML the circumstances when /usr/libexec/qemu-bridge-helper will be used? If so, virt-aa-helper could add the access only then. As a side-benefit, handling this in virt-aa-helper allows us at compile-time to adjust the path to qemu-bridge-helper to use the configured path to the binary (ie, some distros may not use /usr/libexec).
Thanks a lot reviewing the apparmor patch. We cannot detemine from the domain XML whether /usr/libexec/qemu-bridge-helper will be used or not because we cannot determine whether we are running as privileged user or not. Hmmm, that's too bad.
Is there a way we can specify the configured path to the binary in the current policy we have?
Not in a convenient way, no. The policy is intended as example policy anyway, and distributions are expected to modify this, so I don't think this alone is a blocker. -- Jamie Strandboge | http://www.canonical.com