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

[rmarwah at linux.vnet.ibm.com]

Quoting Jamie Strandboge <jamie at canonical.com>:

> On Mon, 2012-07-09 at 10:22 -0400, rmarwah at linux.vnet.ibm.com wrote:
>> Quoting Jamie Strandboge <jamie at canonical.com>:
>>
>> > 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.
>>
>> Right now the only way we can think of is that whenever in domain XML
>> we see interface=bridge
>> we set the policy for the qemu-bridge-helper even though we don't know
>> if the qemu-bridge-helper
>> is going to be used or not.
>
> Ah, well, that would at least be somewhat better and IMHO, worthwhile.
>
Hi Jamie

As we discussed earlier that we cannot determine from the domain XML  
whether the user is
privileged or not to have the generation of the apparmor policy for  
qemu-bridge-helper. One
main purpose of doing this was to get the adjustment of the path of  
the qemu-bridge-helper as
some distros don't have /usr/libexec. So I tried to have the  
generation of the policies be done
when we see interface = bridge in the domain XML. In the process of  
doing so it comes out that
there is not a good way to determine the location of the  
qemu-bridge-helper other than the fact that
it is hard-coded in the virt-aa-helper code. Also could not find a  
good way to have the generation of the child profile for  
qemu-bridge-helper apparmor policy.
Since we have to hard-code the path of the executable I would suggest  
that we keep the apparmor policies for
qemu-bridge-helper in libvirt-qemu only.
Kindly let me know your thoughts.

Regards
Richa

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