[libvirt] [PATCH/RFC] Add missing delta from Ubuntu to apparmor profiles
This had been on the Debian package list before but its time to take this onwards. So the goal would be to have one set to rule them all (when using apparmor) and drop the seperate set of definitions which exist at least in the Ubuntu packaging. Right now the patch would be at a state which adds all missing files and rules to the current examples in libvirt and installs them when using --with-apparmor-profiles. One problem seems to be that some of the definitions might cause parse failures on certain versions of apparmor. I checked this morning and this looks a bit hairy. So some apparmor 2.8 versions potentially have issues, but not all apparmor 2.8 are the same (gah). I could imagine (but John, we really could use some guidance here ;)) that at least some changes could be related to version 2.8.95~2430: + debian/patches/mediate-signals.patch, debian/patches/change-signal-syntax.patch: Parse signal rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. + debian/patches/change-ptrace-syntax.patch, debian/patches/mediate-ptrace.patch: Parse ptrace rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. But, regardless of the when, the apparmor rules maybe need a way to handle versioned features of the parser. One proposal was to comment out problematic rules and allow the packager to re-enable things. Maybe going one step further and have some pre-processing that handles version based sections (like #if (APPARMOR_VERSION >= xxx)). So that is where we stand. Ideas are very welcome. -Stefan ---
From aec5cf8cc30c80492a37856626264c3d4c27a31f Mon Sep 17 00:00:00 2001 From: Stefan Bader <stefan.bader@canonical.com> Date: Thu, 18 Sep 2014 14:15:17 +0200 Subject: [PATCH] Add missing delta from Ubuntu to apparmor profiles
This fixes up the upstream profiles and would allow to drop apparmor related delta from the Ubuntu package. Thanks to Serge Hallyn for the Makefile.am install hook that allows to rename the local file. Signed-off-by: Stefan Bader <stefan.bader@canonical.com> --- examples/apparmor/Makefile.am | 10 ++++++++ examples/apparmor/libvirt-lxc | 15 +++++++++++- examples/apparmor/libvirt-qemu | 31 +++++++++++++++++++++++- examples/apparmor/local-usr.sbin.libvirtd | 2 ++ examples/apparmor/usr.lib.libvirt.virt-aa-helper | 25 ++++++++++++++++--- examples/apparmor/usr.sbin.libvirtd | 17 ++++++++++++- 6 files changed, 94 insertions(+), 6 deletions(-) create mode 100644 examples/apparmor/local-usr.sbin.libvirtd diff --git a/examples/apparmor/Makefile.am b/examples/apparmor/Makefile.am index 7a20e16..aa46cb9 100644 --- a/examples/apparmor/Makefile.am +++ b/examples/apparmor/Makefile.am @@ -20,6 +20,7 @@ EXTRA_DIST= \ libvirt-qemu \ libvirt-lxc \ usr.lib.libvirt.virt-aa-helper \ + local-usr.sbin.libvirtd \ usr.sbin.libvirtd if WITH_APPARMOR_PROFILES @@ -29,6 +30,15 @@ apparmor_DATA = \ usr.sbin.libvirtd \ $(NULL) +localdir = $(apparmordir)/local +local_DATA = \ + local-usr.sbin.libvirtd \ + $(NULL) + +install-data-hook: + mv $(DESTDIR)$(localdir)/local-usr.sbin.libvirtd \ + $(DESTDIR)$(localdir)/usr.sbin.libvirtd + abstractionsdir = $(apparmordir)/abstractions abstractions_DATA = \ libvirt-qemu \ diff --git a/examples/apparmor/libvirt-lxc b/examples/apparmor/libvirt-lxc index 4bfb503..4705e0a 100644 --- a/examples/apparmor/libvirt-lxc +++ b/examples/apparmor/libvirt-lxc @@ -1,12 +1,18 @@ -# Last Modified: Fri Feb 7 13:01:36 2014 +# Last Modified: Thu, 18 Sep 2014 13:56:49 +0200 #include <abstractions/base> umount, + dbus, + signal, + ptrace, # ignore DENIED message on / remount deny mount options=(ro, remount) -> /, + # support use of cgmanager proxy + mount options=(move) /sys/fs/cgroup/cgmanager/ -> /sys/fs/cgroup/cgmanager.lower/, + # allow tmpfs mounts everywhere mount fstype=tmpfs, @@ -33,8 +39,15 @@ mount fstype=fusectl -> /sys/fs/fuse/connections/, mount fstype=securityfs -> /sys/kernel/security/, mount fstype=debugfs -> /sys/kernel/debug/, + deny mount fstype=debugfs -> /var/lib/ureadahead/debugfs/, mount fstype=proc -> /proc/, mount fstype=sysfs -> /sys/, + + mount options=(rw nosuid nodev noexec remount) -> /sys/, + mount options=(rw remount) -> /sys/kernel/security/, + mount options=(rw remount) -> /sys/fs/pstore/, + mount options=(ro remount) -> /sys/fs/pstore/, + deny /sys/firmware/efi/efivars/** rwklx, deny /sys/kernel/security/** rwklx, diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index c6de6dd..b69e64c 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -1,4 +1,4 @@ -# Last Modified: Wed Sep 3 21:52:03 2014 +# Last Modified: Thu, 18 Sep 2014 16:41:21 +0200 #include <abstractions/base> #include <abstractions/consoles> @@ -13,15 +13,22 @@ capability setgid, capability setuid, + # this is needed with libcap-ng support, however it breaks a lot of things + # atm, so just silence the denial until libcap-ng works right. LP: #522845 + deny capability setpcap, + network inet stream, network inet6 stream, /dev/net/tun rw, + /dev/tap* rw, /dev/kvm rw, /dev/ptmx rw, /dev/kqemu rw, @{PROC}/*/status r, @{PROC}/sys/kernel/cap_last_cap r, + owner @{PROC}/*/auxv r, + @{PROC}/sys/vm/overcommit_memory r, # For hostdev access. The actual devices will be added dynamically /sys/bus/usb/devices/ r, @@ -38,6 +45,9 @@ /dev/snd/* rw, capability ipc_lock, # spice + /usr/bin/qemu-system-i386-spice rmix, + /usr/bin/qemu-system-x86_64-spice rmix, + /{dev,run}/shm/ r, owner /{dev,run}/shm/spice.* rw, # 'kill' is not required for sound and is a security risk. Do not enable # unless you absolutely need it. @@ -73,6 +83,7 @@ # the various binaries /usr/bin/kvm rmix, /usr/bin/qemu rmix, + /usr/bin/qemu-system-aarch64 rmix, /usr/bin/qemu-system-arm rmix, /usr/bin/qemu-system-cris rmix, /usr/bin/qemu-system-i386 rmix, @@ -91,6 +102,7 @@ /usr/bin/qemu-system-sparc rmix, /usr/bin/qemu-system-sparc64 rmix, /usr/bin/qemu-system-x86_64 rmix, + /usr/bin/qemu-system-x86_64-spice rmix, /usr/bin/qemu-alpha rmix, /usr/bin/qemu-arm rmix, /usr/bin/qemu-armeb rmix, @@ -117,6 +129,16 @@ /bin/dash rmix, /bin/dd rmix, /bin/cat rmix, + /etc/pki/CA/ r, + /etc/pki/CA/* r, + /etc/pki/libvirt/ r, + /etc/pki/libvirt/** r, + + # for rbd + /etc/ceph/ceph.conf r, + + # for access to hugepages + owner "/run/hugepages/kvm/libvirt/qemu/**" rw, # for usb access /dev/bus/usb/ r, @@ -124,6 +146,13 @@ /sys/bus/ r, /sys/class/ r, + signal (receive) peer=/usr/sbin/libvirtd, + ptrace (tracedby) peer=/usr/sbin/libvirtd, + + # for ppc device-tree access + @{PROC}/device-tree/ r, + @{PROC}/device-tree/** r, + /usr/{lib,libexec}/qemu-bridge-helper Cx -> qemu_bridge_helper, # child profile for bridge helper process profile qemu_bridge_helper { diff --git a/examples/apparmor/local-usr.sbin.libvirtd b/examples/apparmor/local-usr.sbin.libvirtd new file mode 100644 index 0000000..6e19f20 --- /dev/null +++ b/examples/apparmor/local-usr.sbin.libvirtd @@ -0,0 +1,2 @@ +# Site-specific additions and overrides for usr.sbin.libvirtd. +# For more details, please see /etc/apparmor.d/local/README. diff --git a/examples/apparmor/usr.lib.libvirt.virt-aa-helper b/examples/apparmor/usr.lib.libvirt.virt-aa-helper index bceaaff..4df86b0 100644 --- a/examples/apparmor/usr.lib.libvirt.virt-aa-helper +++ b/examples/apparmor/usr.lib.libvirt.virt-aa-helper @@ -1,8 +1,9 @@ -# Last Modified: Mon Apr 5 15:10:27 2010 +# Last Modified: Thu, 18 Sep 2014 14:05:36 +0200 #include <tunables/global> /usr/lib/libvirt/virt-aa-helper { #include <abstractions/base> + #include <abstractions/user-tmp> # needed for searching directories capability dac_override, @@ -19,6 +20,12 @@ # for hostdev /sys/devices/ r, /sys/devices/** r, + /sys/bus/usb/devices/ r, + /sys/bus/usb/devices/** r, + deny /dev/sd* r, + deny /dev/dm-* r, + deny /dev/mapper/ r, + deny /dev/mapper/* r, /usr/lib/libvirt/virt-aa-helper mr, /sbin/apparmor_parser Ux, @@ -26,8 +33,11 @@ /etc/apparmor.d/libvirt/* r, /etc/apparmor.d/libvirt/libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]* rw, - # for backingstore -- allow access to non-hidden files in @{HOME} as well - # as storage pools + # For backingstore, virt-aa-helper needs to peek inside the disk image, so + # allow access to non-hidden files in @{HOME} as well as storage pools, and + # removable media and filesystems, and certain file extentions. A + # virt-aa-helper failure when checking a disk for backinsgstore is non-fatal + # (but obviously the backingstore won't be added). audit deny @{HOME}/.* mrwkl, audit deny @{HOME}/.*/ rw, audit deny @{HOME}/.*/** mrwkl, @@ -35,8 +45,17 @@ audit deny @{HOME}/bin/** mrwkl, @{HOME}/ r, @{HOME}/** r, + @{HOME}/.Private/** mrwlk, + @{HOMEDIRS}/.ecryptfs/*/.Private/** mrwlk, + /var/lib/libvirt/images/ r, /var/lib/libvirt/images/** r, + /var/lib/nova/images/** r, + /var/lib/nova/instances/_base/** r, + /var/lib/nova/instances/snapshots/** r, + /var/lib/eucalyptus/instances/**/disk* r, + /var/lib/eucalyptus/instances/**/loader* r, + /var/lib/uvtool/libvirt/images/** r, /{media,mnt,opt,srv}/** r, /**.img r, diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd index 3011eff..814b4d81 100644 --- a/examples/apparmor/usr.sbin.libvirtd +++ b/examples/apparmor/usr.sbin.libvirtd @@ -1,10 +1,12 @@ -# Last Modified: Mon Apr 5 15:03:58 2010 +# Last Modified: Tue, 23 Sep 2014 09:28:07 +0200 #include <tunables/global> @{LIBVIRT}="libvirt" /usr/sbin/libvirtd { #include <abstractions/base> #include <abstractions/dbus> + # Site-specific additions and overrides. See local/README for details. + #include <local/usr.sbin.libvirtd> capability kill, capability net_admin, @@ -23,6 +25,7 @@ capability setpcap, capability mknod, capability fsetid, + capability ipc_lock, capability audit_write, # Needed for vfio @@ -33,6 +36,12 @@ network inet6 stream, network inet6 dgram, network packet dgram, + network netlink, + + dbus bus=system, + signal, + ptrace, + unix, # Very lenient profile for libvirtd since we want to first focus on confining # the guests. Guests will have a very restricted profile. @@ -45,6 +54,12 @@ /usr/sbin/* PUx, /lib/udev/scsi_id PUx, /usr/lib/xen-common/bin/xen-toolstack PUx, + /usr/lib/xen-*/bin/pygrub PUx, + /usr/lib/xen-*/bin/libxl-save-helper PUx, + + # Required by nwfilter_ebiptables_driver.c:ebiptablesWriteToTempFile() to + # write and run an ebtables script. + /var/lib/libvirt/virtd* ixr, # force the use of virt-aa-helper audit deny /sbin/apparmor_parser rwxl, -- 1.9.1
On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote:
This had been on the Debian package list before but its time to take this onwards. So the goal would be to have one set to rule them all (when using apparmor) and drop the seperate set of definitions which exist at least in the Ubuntu packaging.
Right now the patch would be at a state which adds all missing files and rules to the current examples in libvirt and installs them when using --with-apparmor-profiles.
One problem seems to be that some of the definitions might cause parse failures on certain versions of apparmor. I checked this morning and this looks a bit hairy. So some apparmor 2.8 versions potentially have issues, but not all apparmor 2.8 are the same (gah).
What versions of apparmour are present in the currently supported versions of Debian & Ubuntu ?
I could imagine (but John, we really could use some guidance here ;)) that at least some changes could be related to version 2.8.95~2430:
+ debian/patches/mediate-signals.patch, debian/patches/change-signal-syntax.patch: Parse signal rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. + debian/patches/change-ptrace-syntax.patch, debian/patches/mediate-ptrace.patch: Parse ptrace rules with apparmor_parser. See the apparmor.d(5) man page for syntax details.
But, regardless of the when, the apparmor rules maybe need a way to handle versioned features of the parser. One proposal was to comment out problematic rules and allow the packager to re-enable things. Maybe going one step further and have some pre-processing that handles version based sections (like #if (APPARMOR_VERSION >= xxx)).
I think it would be pretty reasonable to rename the files in have '.in' suffixes, and then have a build script that expands 'if APPARMOR_VERSION' conditionals to generate the final file. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 01.10.2014 11:04, Daniel P. Berrange wrote:
On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote:
This had been on the Debian package list before but its time to take this onwards. So the goal would be to have one set to rule them all (when using apparmor) and drop the seperate set of definitions which exist at least in the Ubuntu packaging.
Right now the patch would be at a state which adds all missing files and rules to the current examples in libvirt and installs them when using --with-apparmor-profiles.
One problem seems to be that some of the definitions might cause parse failures on certain versions of apparmor. I checked this morning and this looks a bit hairy. So some apparmor 2.8 versions potentially have issues, but not all apparmor 2.8 are the same (gah).
What versions of apparmour are present in the currently supported versions of Debian & Ubuntu ?
The way release are handled in Ubuntu (once released there is usually no backporting) we would have to worry less about supported releases. For the Debian side I would think this is similar (correct me if I am wrong, please). So it looks to me that right now this would be down to Debian having 2.8.0 in unstable/testing and Ubuntu having 2.8.96~2652 in Utopic (with the same version in Debian experimental). Right now I would expect it to boil down to those two. But I suppose the parser can change again and so there might be a similar situation in the future. -Stefan
I could imagine (but John, we really could use some guidance here ;)) that at least some changes could be related to version 2.8.95~2430:
+ debian/patches/mediate-signals.patch, debian/patches/change-signal-syntax.patch: Parse signal rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. + debian/patches/change-ptrace-syntax.patch, debian/patches/mediate-ptrace.patch: Parse ptrace rules with apparmor_parser. See the apparmor.d(5) man page for syntax details.
But, regardless of the when, the apparmor rules maybe need a way to handle versioned features of the parser. One proposal was to comment out problematic rules and allow the packager to re-enable things. Maybe going one step further and have some pre-processing that handles version based sections (like #if (APPARMOR_VERSION >= xxx)).
I think it would be pretty reasonable to rename the files in have '.in' suffixes, and then have a build script that expands 'if APPARMOR_VERSION' conditionals to generate the final file.
Regards, Daniel
Quoting Stefan Bader (stefan.bader@canonical.com):
On 01.10.2014 11:04, Daniel P. Berrange wrote:
On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote:
This had been on the Debian package list before but its time to take this onwards. So the goal would be to have one set to rule them all (when using apparmor) and drop the seperate set of definitions which exist at least in the Ubuntu packaging.
Right now the patch would be at a state which adds all missing files and rules to the current examples in libvirt and installs them when using --with-apparmor-profiles.
One problem seems to be that some of the definitions might cause parse failures on certain versions of apparmor. I checked this morning and this looks a bit hairy. So some apparmor 2.8 versions potentially have issues, but not all apparmor 2.8 are the same (gah).
What versions of apparmour are present in the currently supported versions of Debian & Ubuntu ?
The way release are handled in Ubuntu (once released there is usually no backporting) we would have to worry less about supported releases. For the Debian side I would think this is similar (correct me if I am wrong, please). So it looks to me that right now this would be down to Debian having 2.8.0 in unstable/testing and Ubuntu having 2.8.96~2652 in Utopic (with the same version in Debian experimental).
Right now I would expect it to boil down to those two. But I suppose the parser can change again and so there might be a similar situation in the future.
There's also opensuse plus presumably people running hand-built systems.
-Stefan
I could imagine (but John, we really could use some guidance here ;)) that at least some changes could be related to version 2.8.95~2430:
+ debian/patches/mediate-signals.patch, debian/patches/change-signal-syntax.patch: Parse signal rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. + debian/patches/change-ptrace-syntax.patch, debian/patches/mediate-ptrace.patch: Parse ptrace rules with apparmor_parser. See the apparmor.d(5) man page for syntax details.
But, regardless of the when, the apparmor rules maybe need a way to handle versioned features of the parser. One proposal was to comment out problematic rules and allow the packager to re-enable things. Maybe going one step further and have some pre-processing that handles version based sections (like #if (APPARMOR_VERSION >= xxx)).
I think it would be pretty reasonable to rename the files in have '.in' suffixes, and then have a build script that expands 'if APPARMOR_VERSION' conditionals to generate the final file.
Yeah, I think we need to do that. We just need to check the versions for (1) dbus, (2) signal+ptrace, and (3) unix.
On 10/01/2014 04:04 AM, Daniel P. Berrange wrote:
On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote:
This had been on the Debian package list before but its time to take this onwards. So the goal would be to have one set to rule them all (when using apparmor) and drop the seperate set of definitions which exist at least in the Ubuntu packaging.
Right now the patch would be at a state which adds all missing files and rules to the current examples in libvirt and installs them when using --with-apparmor-profiles.
One problem seems to be that some of the definitions might cause parse failures on certain versions of apparmor. I checked this morning and this looks a bit hairy. So some apparmor 2.8 versions potentially have issues, but not all apparmor 2.8 are the same (gah).
What versions of apparmour are present in the currently supported versions of Debian & Ubuntu ?
I could imagine (but John, we really could use some guidance here ;)) that at least some changes could be related to version 2.8.95~2430:
+ debian/patches/mediate-signals.patch, debian/patches/change-signal-syntax.patch: Parse signal rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. + debian/patches/change-ptrace-syntax.patch, debian/patches/mediate-ptrace.patch: Parse ptrace rules with apparmor_parser. See the apparmor.d(5) man page for syntax details.
But, regardless of the when, the apparmor rules maybe need a way to handle versioned features of the parser. One proposal was to comment out problematic rules and allow the packager to re-enable things. Maybe going one step further and have some pre-processing that handles version based sections (like #if (APPARMOR_VERSION >= xxx)).
I think it would be pretty reasonable to rename the files in have '.in' suffixes, and then have a build script that expands 'if APPARMOR_VERSION' conditionals to generate the final file.
These are the rules that are problematic: dbus, ptrace, signal and unix. All of these are not part of upstream apparmor 2.8 proper, but are part of the upcoming 2.9 release. Ubuntu is using prereleases of upstream apparmor 2.9 where 2.8.95 has dbus, ptrace and signal rules and 2.8.96 adds unix rules (unfortunately, Ubuntu introduced dbus rules as a patch on top of apparmor 2.8.0 in 2.8.0-0ubuntu25 for Ubuntu 13.10-- however, Ubuntu 13.10 is EOL now so I think it is fine to not consider this). If we were to decide to adjust the rules based on apparmor version, then please add dbus, ptrace, signal and unix rules based on APPARMOR_VERSION >= 2.9. Distributions like Ubuntu using a prerelease version of AppArmor can then choose to adjust the APPARMOR_VERSION check. IIUC Debian and SUSE will continue to use use official 2.8 until 2.9 becomes official[1]. Thanks [1] AppArmor upstream is working on finalizing the 2.9 release now -- Jamie Strandboge http://www.ubuntu.com/
On Wed, Oct 01, 2014 at 09:46:08AM -0500, Jamie Strandboge wrote:
On 10/01/2014 04:04 AM, Daniel P. Berrange wrote:
On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote:
This had been on the Debian package list before but its time to take this onwards. So the goal would be to have one set to rule them all (when using apparmor) and drop the seperate set of definitions which exist at least in the Ubuntu packaging.
Right now the patch would be at a state which adds all missing files and rules to the current examples in libvirt and installs them when using --with-apparmor-profiles.
One problem seems to be that some of the definitions might cause parse failures on certain versions of apparmor. I checked this morning and this looks a bit hairy. So some apparmor 2.8 versions potentially have issues, but not all apparmor 2.8 are the same (gah).
What versions of apparmour are present in the currently supported versions of Debian & Ubuntu ?
I could imagine (but John, we really could use some guidance here ;)) that at least some changes could be related to version 2.8.95~2430:
+ debian/patches/mediate-signals.patch, debian/patches/change-signal-syntax.patch: Parse signal rules with apparmor_parser. See the apparmor.d(5) man page for syntax details. + debian/patches/change-ptrace-syntax.patch, debian/patches/mediate-ptrace.patch: Parse ptrace rules with apparmor_parser. See the apparmor.d(5) man page for syntax details.
But, regardless of the when, the apparmor rules maybe need a way to handle versioned features of the parser. One proposal was to comment out problematic rules and allow the packager to re-enable things. Maybe going one step further and have some pre-processing that handles version based sections (like #if (APPARMOR_VERSION >= xxx)).
I think it would be pretty reasonable to rename the files in have '.in' suffixes, and then have a build script that expands 'if APPARMOR_VERSION' conditionals to generate the final file.
These are the rules that are problematic: dbus, ptrace, signal and unix. All of these are not part of upstream apparmor 2.8 proper, but are part of the upcoming 2.9 release. Ubuntu is using prereleases of upstream apparmor 2.9 where 2.8.95 has dbus, ptrace and signal rules and 2.8.96 adds unix rules (unfortunately, Ubuntu introduced dbus rules as a patch on top of apparmor 2.8.0 in 2.8.0-0ubuntu25 for Ubuntu 13.10-- however, Ubuntu 13.10 is EOL now so I think it is fine to not consider this).
If we were to decide to adjust the rules based on apparmor version, then please add dbus, ptrace, signal and unix rules based on APPARMOR_VERSION >= 2.9. Distributions like Ubuntu using a prerelease version of AppArmor can then choose to adjust the APPARMOR_VERSION check. IIUC Debian and SUSE will continue to use use official 2.8 until 2.9 becomes official[1].
Agreed, the libvirt upstream distributed file should do version checks based on official apparmor releases, and distros can tweak versions if they have backported features. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi, Daniel P. Berrange wrote (01 Oct 2014 14:54:43 GMT) :
Agreed, the libvirt upstream distributed file should do version checks based on official apparmor releases, and distros can tweak versions if they have backported features.
So, it seems that we've reached a consensus that adding version checking machinery makes sense. Great :) Stefan, do you plan to implement it? One way to go could be to implement and upload it first in Ubuntu: the rest of the delta is already there anyway, so it's not as if it changed the current situation much; and then, it also makes it easy to test the version checks on Debian, for added confidence, before submitting the patch upstream. Note: once this machinery is in place, ideally distros should rebuild their libvirt binary packages when they introduce new AppArmor parser features -- which is effectively a transition, in Debian-speak. Cheers, -- intrigeri
On 18.10.2014 23:12, intrigeri wrote:
Hi,
Daniel P. Berrange wrote (01 Oct 2014 14:54:43 GMT) :
Agreed, the libvirt upstream distributed file should do version checks based on official apparmor releases, and distros can tweak versions if they have backported features.
So, it seems that we've reached a consensus that adding version checking machinery makes sense. Great :)
Stefan, do you plan to implement it? One way to go could be to implement and upload it first in Ubuntu: the rest of the delta is already there anyway, so it's not as if it changed the current situation much; and then, it also makes it easy to test the version checks on Debian, for added confidence, before submitting the patch upstream.
Note: once this machinery is in place, ideally distros should rebuild their libvirt binary packages when they introduce new AppArmor parser features -- which is effectively a transition, in Debian-speak.
Cheers,
Yeah, I actually did but it felt a bit hackish but then I am told anything looks a bit hackish when it involves autoconf. These are again against upstream libvirt mostly because the last touch timestamps always clash otherwise. I tried to do two steps, one introducing the machinery and the second to add the changes. That way the vast looking delta of the first patch boils down to mostly renames. -Stefan
Hi Stefan, Stefan Bader wrote (19 Oct 2014 11:07:40 GMT) :
Yeah, I actually did but it felt a bit hackish but then I am told anything looks a bit hackish when it involves autoconf. These are again against upstream libvirt mostly because the last touch timestamps always clash otherwise.
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. Attempting to build the resulting source package in a clean sid chroot fails here: Making all in examples/apparmor make[3]: Entering directory '/tmp/buildd/libvirt-1.2.9/debian/build/examples/apparmor' make[3]: Circular ../../config.h <- ../../config.h dependency dropped. ./profile-preprocess ../../../../examples/apparmor/libvirt-qemu.in >libvirt-qemu ./profile-preprocess ../../../../examples/apparmor/libvirt-lxc.in >libvirt-lxc ./profile-preprocess ../../../../examples/apparmor/usr.lib.libvirt.virt-aa-helper.in >usr.lib.libvirt.virt-aa-helper ./profile-preprocess ../../../../examples/apparmor/usr.sbin.libvirtd.in >usr.sbin.libvirtd make[3]: *** No rule to make target 'local-usr.sbin.libvirtd', needed by 'all-am'. Stop. make[3]: *** Waiting for unfinished jobs.... /bin/bash: ./profile-preprocess: No such file or directory /bin/bash: ./profile-preprocess: No such file or directory Makefile:2068: recipe for target 'libvirt-qemu' failed make[3]: *** [libvirt-qemu] Error 127 Makefile:2068: recipe for target 'libvirt-lxc' failed make[3]: *** [libvirt-lxc] Error 127 /bin/bash: ./profile-preprocess: No such file or directory /bin/bash: ./profile-preprocess: No such file or directory Makefile:2068: recipe for target 'usr.lib.libvirt.virt-aa-helper' failed make[3]: *** [usr.lib.libvirt.virt-aa-helper] Error 127 Makefile:2068: recipe for target 'usr.sbin.libvirtd' failed make[3]: *** [usr.sbin.libvirtd] Error 127 make[3]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build/examples/apparmor' Makefile:1979: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build' Makefile:1877: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build' dh_auto_build: make -j5 returned exit code 2 debian/rules:126: recipe for target 'build' failed make: *** [build] Error 2 Any hint? Cheers, -- intrigeri
On 19.10.2014 17:07, intrigeri wrote:
Hi Stefan,
Stefan Bader wrote (19 Oct 2014 11:07:40 GMT) :
Yeah, I actually did but it felt a bit hackish but then I am told anything looks a bit hackish when it involves autoconf. These are again against upstream libvirt mostly because the last touch timestamps always clash otherwise.
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.
Attempting to build the resulting source package in a clean sid chroot fails here:
Making all in examples/apparmor make[3]: Entering directory '/tmp/buildd/libvirt-1.2.9/debian/build/examples/apparmor' make[3]: Circular ../../config.h <- ../../config.h dependency dropped. ./profile-preprocess ../../../../examples/apparmor/libvirt-qemu.in >libvirt-qemu ./profile-preprocess ../../../../examples/apparmor/libvirt-lxc.in >libvirt-lxc ./profile-preprocess ../../../../examples/apparmor/usr.lib.libvirt.virt-aa-helper.in >usr.lib.libvirt.virt-aa-helper ./profile-preprocess ../../../../examples/apparmor/usr.sbin.libvirtd.in >usr.sbin.libvirtd make[3]: *** No rule to make target 'local-usr.sbin.libvirtd', needed by 'all-am'. Stop. make[3]: *** Waiting for unfinished jobs.... /bin/bash: ./profile-preprocess: No such file or directory /bin/bash: ./profile-preprocess: No such file or directory Makefile:2068: recipe for target 'libvirt-qemu' failed make[3]: *** [libvirt-qemu] Error 127 Makefile:2068: recipe for target 'libvirt-lxc' failed make[3]: *** [libvirt-lxc] Error 127 /bin/bash: ./profile-preprocess: No such file or directory /bin/bash: ./profile-preprocess: No such file or directory Makefile:2068: recipe for target 'usr.lib.libvirt.virt-aa-helper' failed make[3]: *** [usr.lib.libvirt.virt-aa-helper] Error 127 Makefile:2068: recipe for target 'usr.sbin.libvirtd' failed make[3]: *** [usr.sbin.libvirtd] Error 127 make[3]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build/examples/apparmor' Makefile:1979: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build' Makefile:1877: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build' dh_auto_build: make -j5 returned exit code 2 debian/rules:126: recipe for target 'build' failed make: *** [build] Error 2
Any hint?
Hm, partially this sounds like the preprocess script is not where it should be and the other part looks like not finding any local-usr-sbin. Could likely be that I need to do something better to make things work in place (as the upstream libvirt instructions suggest) as well as with separate object tree (as it is in Debian). I also saw something about circular dependency on config.h which probably slipped my attention. For most of the problems I guess adding something like $(srcdir) (need to look what this would be actually called) to the pre-process scripts path as well as to the .in files.. -Stefan
Cheers,
On 20.10.2014 12:48, Stefan Bader wrote:
On 19.10.2014 17:07, intrigeri wrote:
Hi Stefan,
Stefan Bader wrote (19 Oct 2014 11:07:40 GMT) :
Yeah, I actually did but it felt a bit hackish but then I am told anything looks a bit hackish when it involves autoconf. These are again against upstream libvirt mostly because the last touch timestamps always clash otherwise.
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.
Attempting to build the resulting source package in a clean sid chroot fails here:
Making all in examples/apparmor make[3]: Entering directory '/tmp/buildd/libvirt-1.2.9/debian/build/examples/apparmor' make[3]: Circular ../../config.h <- ../../config.h dependency dropped. ./profile-preprocess ../../../../examples/apparmor/libvirt-qemu.in >libvirt-qemu ./profile-preprocess ../../../../examples/apparmor/libvirt-lxc.in >libvirt-lxc ./profile-preprocess ../../../../examples/apparmor/usr.lib.libvirt.virt-aa-helper.in >usr.lib.libvirt.virt-aa-helper ./profile-preprocess ../../../../examples/apparmor/usr.sbin.libvirtd.in >usr.sbin.libvirtd make[3]: *** No rule to make target 'local-usr.sbin.libvirtd', needed by 'all-am'. Stop. make[3]: *** Waiting for unfinished jobs.... /bin/bash: ./profile-preprocess: No such file or directory /bin/bash: ./profile-preprocess: No such file or directory Makefile:2068: recipe for target 'libvirt-qemu' failed make[3]: *** [libvirt-qemu] Error 127 Makefile:2068: recipe for target 'libvirt-lxc' failed make[3]: *** [libvirt-lxc] Error 127 /bin/bash: ./profile-preprocess: No such file or directory /bin/bash: ./profile-preprocess: No such file or directory Makefile:2068: recipe for target 'usr.lib.libvirt.virt-aa-helper' failed make[3]: *** [usr.lib.libvirt.virt-aa-helper] Error 127 Makefile:2068: recipe for target 'usr.sbin.libvirtd' failed make[3]: *** [usr.sbin.libvirtd] Error 127 make[3]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build/examples/apparmor' Makefile:1979: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build' Makefile:1877: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/tmp/buildd/libvirt-1.2.9/debian/build' dh_auto_build: make -j5 returned exit code 2 debian/rules:126: recipe for target 'build' failed make: *** [build] Error 2
Any hint?
Hm, partially this sounds like the preprocess script is not where it should be and the other part looks like not finding any local-usr-sbin. Could likely be that I need to do something better to make things work in place (as the upstream libvirt instructions suggest) as well as with separate object tree (as it is in Debian). I also saw something about circular dependency on config.h which probably slipped my attention. For most of the problems I guess adding something like $(srcdir) (need to look what this would be actually called) to the pre-process scripts path as well as to the .in files..
Turns out that this first attempt was not too good at all. First it does not help to mis-name the new local .in file. Then, using the wildcard form actually causes many more files to be touched than intended (the circular reference hinted that). Lastly I found it might be good to also do something about cleanup. Hope this version works better in general. -Stefan
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
Hi Stefan, any news on what follows? Now that Ubuntu 15.04 has been released, perhaps you'll be able to allocate some cycles to it? :) intrigeri wrote (11 Feb 2015 14:58:54 GMT) :
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
On 19.05.2015 11:54, intrigeri wrote:
Hi Stefan,
any news on what follows? Now that Ubuntu 15.04 has been released, perhaps you'll be able to allocate some cycles to it? :)
Hm was there not something which I was waiting for feedback from you? Though I forgot what exactly that was. And after release is before release, the treadmill never stops... ;-P Since I lost most context by now, I will try to find my most recent proposal again and try to get it moved into present state of packages. -Stefan
intrigeri wrote (11 Feb 2015 14:58:54 GMT) :
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,
Hi, Stefan Bader wrote (20 May 2015 10:11:45 GMT) :
Hm was there not something which I was waiting for feedback from you?
My (possibly incomplete) records say that I've tested the latest proposed patch set back in February (<85iof8v6j5.fsf@boum.org>).
Since I lost most context by now, I will try to find my most recent proposal again and try to get it moved into present state of packages.
Thanks! Cheers, -- intrigeri
Hi,
Stefan Bader wrote (20 May 2015 10:11:45 GMT) : intrigeri wrote (15 Jun 2015 15:09:11 GMT) : My (possibly incomplete) records say that I've tested the latest proposed patch set back in February (<85iof8v6j5.fsf@boum.org>).
Since I lost most context by now, I will try to find my most recent proposal again and try to get it moved into present state of packages.
Ping? Cheers, -- intrigeri
On 09.05.2016 21:00, intrigeri wrote:
Hi,
Stefan Bader wrote (20 May 2015 10:11:45 GMT) : intrigeri wrote (15 Jun 2015 15:09:11 GMT) : My (possibly incomplete) records say that I've tested the latest proposed patch set back in February (<85iof8v6j5.fsf@boum.org>).
Since I lost most context by now, I will try to find my most recent proposal again and try to get it moved into present state of packages.
Ping?
*sigh* yeah (/me look guilty). I am on that now. This time approaching things from the bottom. So I actually have something that seems somehow working with the Ubuntu packaging. I just want to get some internal feedback first. But I should be sending out something around next Monday. The good thing would be that this is against libvirt 1.3.4 which Serge got closer to Debian than ever before. So there is hope that it can be tried in Debian without much problem. -Stefan
Cheers,
Hi, Daniel P. Berrange wrote (01 Oct 2014 09:04:09 GMT) :
I think it would be pretty reasonable to rename the files in have '.in' suffixes, and then have a build script that expands 'if APPARMOR_VERSION' conditionals to generate the final file.
I agree it's the way to go, to avoid that each distro shipping a different version writes the same kind of hacks. Cheers, -- intrigeri
participants (5)
-
Daniel P. Berrange -
intrigeri -
Jamie Strandboge -
Serge Hallyn -
Stefan Bader