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

[Jamie Strandboge]

On Tue, 2012-07-03 at 12:05 -0400, rmarwah at linux.vnet.ibm.com wrote:
> Quoting Jamie Strandboge <jamie at canonical.com>:
> 
> > On Fri, 2012-06-29 at 14:08 -0400, rmarwah at linux.vnet.ibm.com wrote:
> >> From: Richa Marwaha <rmarwah at 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 at linux.vnet.ibm.com>
> >> Signed-off-by: Corey Bryant<coreyb at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120706/11402e72/attachment-0001.sig>