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

[Jamie Strandboge]

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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/attachments/20160730/d2be6cf2/attachment.sig>