[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 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




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