[PATCH] apparmor: allow kvm-spice compat wrapper

[Michal Privoznik]

On 11/18/20 3:11 AM, Neal Gompa wrote:
> On Tue, Nov 17, 2020 at 11:49 AM Christian Ehrhardt
> <christian.ehrhardt at canonical.com> wrote:
>>
>> On Mon, Nov 16, 2020 at 3:28 PM Michal Privoznik <mprivozn at redhat.com> wrote:
>>>
>>> On 11/16/20 1:26 PM, Christian Ehrhardt wrote:
>>>> 'kvm-spice' is a binary name used to call 'kvm' which actually is a wrapper
>>>> around qemu-system-x86_64 enabling kvm acceleration. This isn't in use
>>>> for quite a while anymore, but required to work for compatibility e.g.
>>>> when migrating in old guests.
>>>>
>>>> For years this was a symlink kvm-spice->kvm and therefore covered
>>>> apparmor-wise by the existing entry:
>>>>      /usr/bin/kvm rmix,
>>>> But due to a recent change [1] in qemu packaging this now is no symlink,
>>>> but a wrapper on its own and therefore needs an own entry that allows it
>>>> to be executed.
>>>>
>>>> [1]: https://salsa.debian.org/qemu-team/qemu/-/commit/9944836d3
>>>>
>>>> Signed-off-by: Christian Ehrhardt <christian.ehrhardt at canonical.com>
>>>> ---
>>>>    src/security/apparmor/libvirt-qemu | 1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>
>>> Reviewed-by: Michal Privoznik <mprivozn at redhat.com>
>>
>> Thank you Michal,
>> it also passed fine through my tests (as backport to 6.8 and 6.9).
>> We are not in any freeze, review has happened, tests LGTM - pushed to git.
>>
> 
> Hold up, why was this merged? Did anyone validate whether this would
> break the other AppArmor user (SUSE)?
> 
> Unlike SELinux, AppArmor functionality is quite fragmented between
> Ubuntu and SUSE distributions (the two major users of AppArmor), and
> there did not seem to be any indication that this AppArmor patch was
> validated with openSUSE before merging. My personal experience with
> AppArmor across the two distribution families is that it's really easy
> to make profiles that work for Ubuntu but fail on SUSE because of the
> disparity of functionality. I also don't see Jim Fehlig stepping in to
> indicate that this worked for him.
> 
> I haven't had a chance to test this myself, but I am immediately
> suspicious of a change that references a commit based on Debian
> packaging of QEMU.
> 
> 

Maybe I'm misunderstanding something, but does this have a potential of 
breaking something? It's only allowing one binary more that can be executed.

Michal