Hi Stefan and others,
Stefan Bader wrote (21 Oct 2014 11:50:24 GMT) :
On 20.10.2014 12:48, Stefan Bader wrote:
> On 19.10.2014 17:07, intrigeri wrote:
>> Cool, I've tested this. I've imported these two patches in Debian's
>> 1.2.9-3 quilt series, made the build system use dh-autoreconf (the
>> build system in the tarball wants aclocal 1.13, while Debian sid has
>> 1.14), and added a build-dep on libapparmor-dev to get the needed
>> pkg-config file.
I've given a try to your last set of patches. Sorry for the delay.
Here's what I did:
1. Checkout the Vcs-Git libvirt packaging repo for Debian unstable,
currently at 1.2.9-9
2. Make the build system use dh-autoreconf as previously
3. Added the build-dep on libapparmor-dev as previously
4. Hacked debian/rules to make examples/apparmor/profile-preprocess
(created by your patches) executable before it's executed.
This won't be needed anymore once the patches are upstreamed.
5. Build in a clean Debian unstable chroot, which now works.
Progress :)
6. Install the resulting binary packages on a sid system with
a working libvirt setup.
7. In /etc/libvirt/qemu.conf, set security_driver = "apparmor"
8. Restart libvirtd.
9. Start a VM with virsh or virt-manager
=> here's what I see:
error: Failed to start domain tails-dev
error: internal error: cannot load AppArmor profile
'libvirt-14dcf3fa-a4d5-4c5a-82ea-3f624b44c7ef'
And the Journal says:
libvirtd[20351]: internal error: Child process (/usr/lib/libvirt/virt-aa-helper -p 0 -c
-u libvirt-14dcf3fa-a4d5-4c5a-82ea-3f624b44c7ef) unexpected exit status 1: virt-aa-helper:
error: template does not exist
virt-aa-helper: error: could not create profile
libvirtd[20351]: internal error: cannot load AppArmor profile
'libvirt-14dcf3fa-a4d5-4c5a-82ea-3f624b44c7ef'
So I naively tried to do it by hand:
$ virsh dumpxml tails-dev | sudo /usr/lib/libvirt/virt-aa-helper -p 0 -c -u
libvirt-14dcf3fa-a4d5-4c5a-82ea-3f624b44c7ef
virt-aa-helper: error: template does not exist
virt-aa-helper: error: could not create profile
I do have a template in place:
$ cat /etc/apparmor.d/libvirt/TEMPLATE.qemu
#
# This profile is for the domain whose UUID matches this file.
#
#include <tunables/global>
profile LIBVIRT_TEMPLATE {
#include <abstractions/libvirt-qemu>
}
What other information can I provide, or what else should I test?
Also note that I had to add the following line to
usr.lib.libvirt.virt-aa-helper, in order to silence an AppArmor denial
log:
/etc/libnl-3/classid r,
Should this be added to the upstream profile, as is or prefixed by
"deny"?
Cheers,
--
intrigeri