[pkg-apparmor] Bug#805002: Bug#805002: libvirt-client: "virsh attach-disk" fails with AppArmor enabled

[Guido Günther]

Hi Jamie,
On Sat, Jul 30, 2016 at 08:19:50AM -0500, Jamie Strandboge wrote:
> On Sat, 2016-07-30 at 14:06 +0200, intrigeri wrote:
> > Hi,
> > 
> > Guido Günther:
> > > 
> > > On Fri, Nov 13, 2015 at 09:32:15AM +0000, Carlo Rengo wrote:
> > > > 
> > > > Running “virsh attach-disk <domain> <source> <target>” with AppArmor
> > > > enabled and 
> > > > the domain confined in enforce mode gives this error:
> > [...]
> > > 
> > > > 
> > > > audit: type=1400 audit(1447406591.892:2017): apparmor="DENIED"
> > > > operation="open"
> > > > profile="libvirt-73a13868-fbfd-4dce-bbf1-effde396bb12"
> > > > name="/var/lib/libvirt/images/to_attach.img" pid=56392 comm="kvm"
> > > > requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> > [...]
> > > 
> > > > 
> > > > 
> > > > When putting the domain in complain/disabled mode, the error keeps showing
> > > > up until 
> > > > the domain is destroyed/recreated or saved/restored.
> > > 
> > > I can confirm this (see below).
> > > 
> > > > 
> > > > This errors appears with libvirt from debian stable, debian testing and
> > > > from a compiled 
> > > > version of the source. Ubuntu 15.10 is not affected by this bug.
> > > 
> > > I think this issue is not within in libvirt but related to apparmor not
> > > correctly refreshing the profiles of running processes. As outlined in
> > > #826218 I can reproduce this without having virt-aa-helper in the game
> > > (by changing the profile on disk and reloading it into the kernel via
> > > apparmor_parser -r). Can be reproduced via:
> > > 
> > >    echo "/var/lib/libvirt/images/powerpc.img rw," >>
> > > /etc/apparmor.d/libvirt/libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a.files
> > >    chmod u+rw /var/lib/libvirt/images/powerpc.img
> > >    chown libvirt-qemu: /var/lib/libvirt/images/powerpc.img
> > >    /sbin/apparmor_parser -r  /etc/apparmor.d/libvirt/libvirt-a9287b6e-ca06-
> > > 42fe-b1a2-06830752843a
> > >    virsh qemu-monitor-command wheezy --pretty --cmd '{"execute":"human-
> > > monitor-command","arguments":{"command-line":"drive_add dummy file=/var/li
> > AFAIK an already running process is not affected by changes to its
> > AppArmor profile, as "Profiles are applied to a process at exec(3)
> > time" (apparmor(7)).
> > 
> No, you may replace the profile of a process that is already running under that
> profile (see my other response). All VMs are launched under a profile, so it is
> fine to update the profile to add attached files and then reload the profile.
> libvirt's AppArmor backend has been doing exactly that for qemu:///system for
> years.
> 
> I looked at the bug and it is talking about qemu:///session though. Note that
> 'session' is run by the user and CAP_MAC_ADMIN is required to change AppArmor
> security policy. I haven't looked at qemu:///session in ages, but back when I

If the bug talks about qemu:///session this is an error. This is all
about qemu:///system (using either virt-aa-helper or the above "manual"
steps to reproduce). So there seems to be a but in either the kernel or
"apparmor_parser -r" then.

Thanks a lot for your explanation!
 -- Guido

> did, a separate libvirtd ran as the user was used for 'session' (as opposed to
> the root running one for 'system') and as a result it should not be trying to
> modify the policy at all (it doesn't have CAP_MAC_ADMIN and doesn't have write
> access to /etc/apparmor.d/libvirt either). As a result, AppArmor confined VMs
> with qemu:///session can't be (fully) supported at this time. IMO, libvirt
> shouldn't be trying to use/modify AppArmor policy at all with qemu:///session
> and if it is, that is a bug in libvirt.
> 
> That said, we are getting closer to having user-defined policy in AppArmor
> upstream, and when that is available libvirt could be modified to use it with
> qemu:///session.
> 
> Hope this helps
> 
> -- 
> Jamie Strandboge             | http://www.canonical.com