On Tue, Nov 17, 2020 at 11:49 AM Christian Ehrhardt
<christian.ehrhardt(a)canonical.com> wrote:
>
> On Mon, Nov 16, 2020 at 3:28 PM Michal Privoznik <mprivozn(a)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(a)canonical.com>
>>> ---
>>> src/security/apparmor/libvirt-qemu | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>
>> Reviewed-by: Michal Privoznik <mprivozn(a)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