Quoting Jamie Strandboge <jamie@xxxxxxxxxxxxx>:
> On Tue, 2012-07-03 at 12:05 -0400, rmarwah@xxxxxxxxxxxxxxxxxx wrote:
>> Quoting Jamie Strandboge <jamie@xxxxxxxxxxxxx>:
>>
>> > On Fri, 2012-06-29 at 14:08 -0400, rmarwah@xxxxxxxxxxxxxxxxxx wrote:
>> >> From: Richa Marwaha <rmarwah@xxxxxxxxxxxxxxxxxx>
>> >>
>> >> 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@xxxxxxxxxxxxxxxxxx>
>> >> Signed-off-by: Corey Bryant<coreyb@xxxxxxxxxxxxxxxxxx>
>> >> ---
>> >> 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.