Quoting Jamie Strandboge <jamie@canonical.com>:
On Mon, 2012-07-09 at 10:22 -0400, rmarwah@linux.vnet.ibm.com wrote:
Quoting Jamie Strandboge <jamie@canonical.com>:
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.
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