Apparmor denials caused by virt-aa-helper trying to read zvol devices (/dev/zdX) should be silenced
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Fix Released
|
Medium
|
Christian Ehrhardt | ||
Xenial |
Fix Released
|
Low
|
Unassigned |
Bug Description
When a qemu-kvm guest is using a zvol or a DRBD volume or a NVME partition, Apparmor denial messages are logged due to virt-aa-helper trying to access the volume/device. Those should be silenced as it's already done for Logical Volumes.
[Impact]
* libvirt driving guests on more recent backing devices floods logs and
dmesg due to non critical apparmor denials.
* those can distract from real issues and therefore (as with similar
cases in the past) should be silenced by explicit denials.
[Test Case]
1) Create a KVM guest
2) Edit the guest's XML profile to reference a zvol|DRBD volume|NVME partition
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/
<target dev='vda' bus='virtio'/>
</disk>
3) Start the guest
4) Check dmesg for any Apparmor denials, there should be none with the patch
*Without* the patch, one would see those (or similar) denials:
audit: type=1400 audit(147980991
[Regression Potential]
Adding a couple of explicit denials to the virt-aa-helper profile shouldn't cause no harm because Apparmor already denies those, this is just about silencing this.
[Original description]
Libvirt qemu-kvm guests backed by zvols (ZFS volumes) generate useless noise due to virt-aa-helper trying to read the backing device in the host (/dev/zdX). Other host's devs are already denied in virt-aa-helper's profile:
# for hostdev
/sys/devices/ r,
/sys/devices/** r,
/sys/
/sys/
deny /dev/sd* r,
deny /dev/dm-* r,
deny /dev/mapper/ r,
deny /dev/mapper/* r,
Adding "deny /dev/zd[0-9]* r," would silence Apparmor.
Hi Simon,
those changes (the whole part after "/sys/devices/** r,") never made it upstream and was actually dropped in the merge of libvirt 2.x for Yakkety.
Maybe that also moved and this is "only" needed in Xenial and actually fixed in >=Yakkety already?
And looking back - nobody complained on the yakkety merge that smb did - hrm ..?
Eventually (like some day) we want to get rid of apparmor delta and that was one step.
I also checked History backwards but things are a bit lost since for some time Ubuntu was ahead of Debian before switching to the more usual setup.
I almost couldn't find the past but I realized you know the history of this - as I found bug 912007 from you of 2012.
I checked a Yakkety that I had around which did not have the denies as I outlined before.
So following the old bug content I realized it might need special devices. So to reproduce on Yakkety (what I just had around) I added disks on lvm and nvme to see if I can find it:
<disk type='file' device='disk'> dev/mapper/ testvg- testlv' /> dev/nvme0n1' />
<driver name='qemu' type='raw' cache='none'/>
<source file='/
<target dev='vdc' bus='virtio'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/
<target dev='vdd' bus='virtio'/>
</disk>
The LV was silent - although I failed to see what was done in the profile for it.
The nveme I found and I think that is because it is new and not covered yet, the same way zfs might not be there yet. I need to find the spot that makes the "ok" to the LVM as this is clearly the place to add it on newer versions.
Simon: libvirt. virt-aa- helper" , but I don't really get why it is a deny and not an allow - could you elaborate on that?
- Can you describe the "noise" it makes to you?
- Having the old rules you were on Xenial right?
- Does it match what I found?
- The old bug only has "Per discussion on irc, I'll add a deny rule to usr.lib.