[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Patch v2 3/3] apparmor: QEMU bridge helper policy updates

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. Is there a way we can specify the configured path to the binary in the current policy we have?

Richa Marwaha

Jamie Strandboge             | http://www.canonical.com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]