Debian Bug report logs - #725144
libvirt-bin: Please build with apparmor support.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ben Kibbey <bjk@luxsci.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libvirt-bin: Please build with apparmor support.

Date: Tue, 01 Oct 2013 20:00:03 -0400

Package: libvirt-bin
Version: 0.9.12-11+deb7u1
Severity: wishlist

Dear Maintainer,

If possible, please build with apparmor support as an alternative to SELinux.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.3 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libvirt-bin depends on:
ii  adduser             3.113+nmu3
ii  gettext-base        0.18.3.1-1
ii  libavahi-client3    0.6.31-2
ii  libavahi-common3    0.6.31-2
ii  libblkid1           2.20.1-5.5
ii  libc6               2.17-92+b1
ii  libcap-ng0          0.7.3-1+b1
ii  libdbus-1-3         1.6.14-1
ii  libdevmapper1.02.1  2:1.02.77-6+b1
ii  libgcrypt11         1.5.3-2
ii  libgnutls26         2.12.23-7
ii  libnetcf1           1:0.2.0-5
ii  libnl1              1.1-8
ii  libnuma1            2.0.9~rc5-1
ii  libparted0debian1   2.3-16
ii  libpcap0.8          1.4.0-2
ii  libpciaccess0       0.13.2-1
ii  libreadline6        6.2+dfsg-0.1
ii  libsasl2-2          2.1.25.dfsg1-14
ii  libudev0            175-7.2
ii  libvirt0            0.9.12-11+deb7u1
ii  libxenstore3.0      4.1.4-4
ii  libxml2             2.9.1+dfsg1-3
ii  libyajl2            2.0.4-4
ii  logrotate           3.8.6-1

Versions of packages libvirt-bin recommends:
ii  bridge-utils    1.5-6
ii  dmidecode       2.12-2
ii  dnsmasq-base    2.66-4
pn  ebtables        <none>
ii  gawk            1:4.0.1+dfsg-2.1
ii  iproute         1:3.11.0-1
ii  iptables        1.4.20-2
ii  libxml2-utils   2.9.1+dfsg1-3
ii  netcat-openbsd  1.105-7
ii  parted          2.3-16
ii  qemu            1.1.2+dfsg-6a
ii  qemu-kvm        1.1.2+dfsg-6

Versions of packages libvirt-bin suggests:
ii  policykit-1  0.105-3
ii  radvd        1:1.9.1-1.1

-- Configuration Files:
/etc/default/libvirt-guests changed [not included]
/etc/libvirt/libvirtd.conf changed [not included]

-- no debconf information

Message #10 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Ben Kibbey <bjk@luxsci.net>, 725144@bugs.debian.org

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Wed, 2 Oct 2013 18:58:46 +0200

On Tue, Oct 01, 2013 at 08:00:03PM -0400, Ben Kibbey wrote:
> Package: libvirt-bin
> Version: 0.9.12-11+deb7u1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> If possible, please build with apparmor support as an alternative to SELinux.

Did you test the build with app armor support in any way yet?
Cheers,
 -- Guido

> 
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (400, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.11.3 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages libvirt-bin depends on:
> ii  adduser             3.113+nmu3
> ii  gettext-base        0.18.3.1-1
> ii  libavahi-client3    0.6.31-2
> ii  libavahi-common3    0.6.31-2
> ii  libblkid1           2.20.1-5.5
> ii  libc6               2.17-92+b1
> ii  libcap-ng0          0.7.3-1+b1
> ii  libdbus-1-3         1.6.14-1
> ii  libdevmapper1.02.1  2:1.02.77-6+b1
> ii  libgcrypt11         1.5.3-2
> ii  libgnutls26         2.12.23-7
> ii  libnetcf1           1:0.2.0-5
> ii  libnl1              1.1-8
> ii  libnuma1            2.0.9~rc5-1
> ii  libparted0debian1   2.3-16
> ii  libpcap0.8          1.4.0-2
> ii  libpciaccess0       0.13.2-1
> ii  libreadline6        6.2+dfsg-0.1
> ii  libsasl2-2          2.1.25.dfsg1-14
> ii  libudev0            175-7.2
> ii  libvirt0            0.9.12-11+deb7u1
> ii  libxenstore3.0      4.1.4-4
> ii  libxml2             2.9.1+dfsg1-3
> ii  libyajl2            2.0.4-4
> ii  logrotate           3.8.6-1
> 
> Versions of packages libvirt-bin recommends:
> ii  bridge-utils    1.5-6
> ii  dmidecode       2.12-2
> ii  dnsmasq-base    2.66-4
> pn  ebtables        <none>
> ii  gawk            1:4.0.1+dfsg-2.1
> ii  iproute         1:3.11.0-1
> ii  iptables        1.4.20-2
> ii  libxml2-utils   2.9.1+dfsg1-3
> ii  netcat-openbsd  1.105-7
> ii  parted          2.3-16
> ii  qemu            1.1.2+dfsg-6a
> ii  qemu-kvm        1.1.2+dfsg-6
> 
> Versions of packages libvirt-bin suggests:
> ii  policykit-1  0.105-3
> ii  radvd        1:1.9.1-1.1
> 
> -- Configuration Files:
> /etc/default/libvirt-guests changed [not included]
> /etc/libvirt/libvirtd.conf changed [not included]
> 
> -- no debconf information
> 
> _______________________________________________
> Pkg-libvirt-maintainers mailing list
> Pkg-libvirt-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
> 

Message #15 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Ben Kibbey <bjk@luxsci.net>

To: Guido Günther <agx@sigxcpu.org>

Cc: 725144@bugs.debian.org

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Wed, 02 Oct 2013 20:47:18 -0400

On Wed, 2 Oct 2013 18:58:46 +0200, Guido Günther writes:
> On Tue, Oct 01, 2013 at 08:00:03PM -0400, Ben Kibbey wrote:
>> Package: libvirt-bin
>> Version: 0.9.12-11+deb7u1
>> Severity: wishlist
>> 
>> Dear Maintainer,
>> 
>> If possible, please build with apparmor support as an alternative to SELinux.
>
> Did you test the build with app armor support in any way yet?
> Cheers,
>  -- Guido

Yes, but I was unable to get it working correctly. It seems
virt-aa-helper doesn't get run when needed. Although, the libvirtd
apparmor profile does get enabled and libvirtd runs correctly.

I've tried creating a new VM with no luck either. What about you? Have
you gotten it to work at all?

-- 
Ben Kibbey

Message #20 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Ben Kibbey <bjk@luxsci.net>

Cc: 725144@bugs.debian.org

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Thu, 3 Oct 2013 11:01:12 +0200

On Wed, Oct 02, 2013 at 08:47:18PM -0400, Ben Kibbey wrote:
> On Wed, 2 Oct 2013 18:58:46 +0200, Guido Günther writes:
> > On Tue, Oct 01, 2013 at 08:00:03PM -0400, Ben Kibbey wrote:
> >> Package: libvirt-bin
> >> Version: 0.9.12-11+deb7u1
> >> Severity: wishlist
> >> 
> >> Dear Maintainer,
> >> 
> >> If possible, please build with apparmor support as an alternative to SELinux.
> >
> > Did you test the build with app armor support in any way yet?
> > Cheers,
> >  -- Guido
> 
> Yes, but I was unable to get it working correctly. It seems
> virt-aa-helper doesn't get run when needed. Although, the libvirtd
> apparmor profile does get enabled and libvirtd runs correctly.
> 
> I've tried creating a new VM with no luck either. What about you? Have
> you gotten it to work at all?

It's not enabled since I never hat time to test and work on it, so if
you want it enable please help and take this upstream and provide the
necessary patches.
Cheers,
 -- Guido

> 
> -- 
> Ben Kibbey
> 

Message #25 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Felix Geyer <fgeyer@debian.org>

To: 725144@bugs.debian.org

Cc: Ben Kibbey <bjk@luxsci.net>

Subject: Re: Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Fri, 03 Jan 2014 22:58:14 +0100

[Message part 1 (text/plain, inline)]

I've ported and tested the libvirt AppArmor support from the Ubuntu package.

The only difference in the profiles is this addition to usr.lib.libvirt.virt-aa-helper:
  /etc/libnl-[0-9]/classid r,

It can be enabled by setting this in /etc/libvirt/qemu.conf:
security_driver = "apparmor"

Cheers,
Felix

PS: Could you please enable parallel building: dh $@ --builddirectory=$(DEB_BUILDDIR) --parallel.
    That makes test-building so much more fun ;)

[libvirt_apparmor.debdiff (text/plain, attachment)]

Message #30 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Felix Geyer <fgeyer@debian.org>, 725144@bugs.debian.org

Cc: Ben Kibbey <bjk@luxsci.net>

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Sat, 4 Jan 2014 18:19:39 +0100

Hi Felix,
On Fri, Jan 03, 2014 at 10:58:14PM +0100, Felix Geyer wrote:
> I've ported and tested the libvirt AppArmor support from the Ubuntu package.
> 
> The only difference in the profiles is this addition to usr.lib.libvirt.virt-aa-helper:
>   /etc/libnl-[0-9]/classid r,
> 
> It can be enabled by setting this in /etc/libvirt/qemu.conf:
> security_driver = "apparmor"

Can you please work on upsreaming this? I don't see why this should be
in the Debian package. Who is going to maintain this policies in the
future?
Cheers,
 -- Guido

> 
> Cheers,
> Felix
> 
> PS: Could you please enable parallel building: dh $@ --builddirectory=$(DEB_BUILDDIR) --parallel.
>     That makes test-building so much more fun ;)

> diff -Nru libvirt-1.2.0/debian/apparmor/libvirt-qemu libvirt-1.2.0/debian/apparmor/libvirt-qemu
> --- libvirt-1.2.0/debian/apparmor/libvirt-qemu	1970-01-01 01:00:00.000000000 +0100
> +++ libvirt-1.2.0/debian/apparmor/libvirt-qemu	2013-11-12 18:47:24.000000000 +0100
> @@ -0,0 +1,140 @@
> +# Last Modified: Wed Jul  8 09:57:41 2009
> +
> +  #include <abstractions/base>
> +  #include <abstractions/consoles>
> +  #include <abstractions/nameservice>
> +
> +  # required for reading disk images
> +  capability dac_override,
> +  capability dac_read_search,
> +  capability chown,
> +
> +  # needed to drop privileges
> +  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,
> +  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,
> +  /sys/devices/**/usb[0-9]*/** r,
> +
> +  # WARNING: this gives the guest direct access to host hardware and specific
> +  # portions of shared memory. This is required for sound using ALSA with kvm,
> +  # but may constitute a security risk. If your environment does not require
> +  # the use of sound in your VMs, feel free to comment out or prepend 'deny' to
> +  # the rules for files in /dev.
> +  /{dev,run}/shm r,
> +  /{dev,run}/shmpulse-shm* r,
> +  /{dev,run}/shmpulse-shm* rwk,
> +  /dev/snd/* rw,
> +  capability ipc_lock,
> +  # spice
> +  /usr/bin/qemu-system-i386-spice rmix,
> +  /usr/bin/qemu-system-x86_64-spice rmix,
> +  /run/shm/ r,
> +  owner /run/shm/spice.* rw,
> +  # 'kill' is not required for sound and is a security risk. Do not enable
> +  # unless you absolutely need it.
> +  deny capability kill,
> +
> +  # Uncomment the following if you need access to /dev/fb*
> +  #/dev/fb* rw,
> +
> +  /etc/pulse/client.conf r,
> +  @{HOME}/.pulse-cookie rwk,
> +  owner /root/.pulse-cookie rwk,
> +  owner /root/.pulse/ rw,
> +  owner /root/.pulse/* rw,
> +  /usr/share/alsa/** r,
> +  owner /tmp/pulse-*/ rw,
> +  owner /tmp/pulse-*/* rw,
> +  /var/lib/dbus/machine-id r,
> +
> +  # access to firmware's etc
> +  /usr/share/kvm/** r,
> +  /usr/share/qemu/** r,
> +  /usr/share/bochs/** r,
> +  /usr/share/openbios/** r,
> +  /usr/share/openhackware/** r,
> +  /usr/share/proll/** r,
> +  /usr/share/vgabios/** r,
> +  /usr/share/seabios/** r,
> +  /usr/share/ovmf/** r,
> +
> +  # access PKI infrastructure
> +  /etc/pki/libvirt-vnc/** r,
> +
> +  # the various binaries
> +  /usr/bin/kvm rmix,
> +  /usr/bin/qemu rmix,
> +  /usr/bin/qemu-system-arm rmix,
> +  /usr/bin/qemu-system-cris rmix,
> +  /usr/bin/qemu-system-i386 rmix,
> +  /usr/bin/qemu-system-m68k rmix,
> +  /usr/bin/qemu-system-mips rmix,
> +  /usr/bin/qemu-system-mips64 rmix,
> +  /usr/bin/qemu-system-mips64el rmix,
> +  /usr/bin/qemu-system-mipsel rmix,
> +  /usr/bin/qemu-system-ppc rmix,
> +  /usr/bin/qemu-system-ppc64 rmix,
> +  /usr/bin/qemu-system-ppcemb rmix,
> +  /usr/bin/qemu-system-sh4 rmix,
> +  /usr/bin/qemu-system-sh4eb rmix,
> +  /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,
> +  /usr/bin/qemu-cris rmix,
> +  /usr/bin/qemu-i386 rmix,
> +  /usr/bin/qemu-m68k rmix,
> +  /usr/bin/qemu-mips rmix,
> +  /usr/bin/qemu-mipsel rmix,
> +  /usr/bin/qemu-ppc rmix,
> +  /usr/bin/qemu-ppc64 rmix,
> +  /usr/bin/qemu-ppc64abi32 rmix,
> +  /usr/bin/qemu-sh4 rmix,
> +  /usr/bin/qemu-sh4eb rmix,
> +  /usr/bin/qemu-sparc rmix,
> +  /usr/bin/qemu-sparc64 rmix,
> +  /usr/bin/qemu-sparc32plus rmix,
> +  /usr/bin/qemu-sparc64 rmix,
> +  /usr/bin/qemu-x86_64 rmix,
> +
> +  # for save and resume
> +  /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,
> +  /etc/udev/udev.conf r,
> +  /sys/bus/ r,
> +  /sys/class/ r,
> diff -Nru libvirt-1.2.0/debian/apparmor/local-usr.sbin.libvirtd libvirt-1.2.0/debian/apparmor/local-usr.sbin.libvirtd
> --- libvirt-1.2.0/debian/apparmor/local-usr.sbin.libvirtd	1970-01-01 01:00:00.000000000 +0100
> +++ libvirt-1.2.0/debian/apparmor/local-usr.sbin.libvirtd	2012-12-05 23:37:34.000000000 +0100
> @@ -0,0 +1,2 @@
> +# Site-specific additions and overrides for usr.sbin.libvirtd.
> +# For more details, please see /etc/apparmor.d/local/README.
> diff -Nru libvirt-1.2.0/debian/apparmor/TEMPLATE libvirt-1.2.0/debian/apparmor/TEMPLATE
> --- libvirt-1.2.0/debian/apparmor/TEMPLATE	1970-01-01 01:00:00.000000000 +0100
> +++ libvirt-1.2.0/debian/apparmor/TEMPLATE	2012-12-05 23:37:34.000000000 +0100
> @@ -0,0 +1,9 @@
> +#
> +# This profile is for the domain whose UUID matches this file.
> +#
> +
> +#include <tunables/global>
> +
> +profile LIBVIRT_TEMPLATE {
> +  #include <abstractions/libvirt-qemu>
> +}
> diff -Nru libvirt-1.2.0/debian/apparmor/usr.lib.libvirt.virt-aa-helper libvirt-1.2.0/debian/apparmor/usr.lib.libvirt.virt-aa-helper
> --- libvirt-1.2.0/debian/apparmor/usr.lib.libvirt.virt-aa-helper	1970-01-01 01:00:00.000000000 +0100
> +++ libvirt-1.2.0/debian/apparmor/usr.lib.libvirt.virt-aa-helper	2014-01-03 22:13:41.000000000 +0100
> @@ -0,0 +1,65 @@
> +# Last Modified: Mon Jul  06 17:22:37 2009
> +#include <tunables/global>
> +
> +/usr/lib/libvirt/virt-aa-helper {
> +  #include <abstractions/base>
> +  #include <abstractions/user-tmp>
> +
> +  # needed for searching directories
> +  capability dac_override,
> +  capability dac_read_search,
> +
> +  # needed for when disk is on a network filesystem
> +  network inet,
> +
> +  deny @{PROC}/[0-9]*/mounts r,
> +  @{PROC}/[0-9]*/net/psched r,
> +  owner @{PROC}/[0-9]*/status r,
> +  @{PROC}/filesystems r,
> +
> +  /etc/libnl-[0-9]/classid r,
> +
> +  # 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,
> +
> +  /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, 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,
> +  @{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/eucalyptus/instances/**/disk* r,
> +  /var/lib/eucalyptus/instances/**/loader* r,
> +  /{media,mnt,opt,srv}/** r,
> +
> +  /**.img r,
> +  /**.qcow{,2} r,
> +  /**.qed r,
> +  /**.vmdk r,
> +  /**.[iI][sS][oO] r,
> +  /**/disk{,.*} r,
> +}
> diff -Nru libvirt-1.2.0/debian/apparmor/usr.sbin.libvirtd libvirt-1.2.0/debian/apparmor/usr.sbin.libvirtd
> --- libvirt-1.2.0/debian/apparmor/usr.sbin.libvirtd	1970-01-01 01:00:00.000000000 +0100
> +++ libvirt-1.2.0/debian/apparmor/usr.sbin.libvirtd	2013-10-23 21:08:59.000000000 +0200
> @@ -0,0 +1,67 @@
> +# Last Modified: Mon Jul  6 17:23:58 2009
> +#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,
> +  capability net_raw,
> +  capability setgid,
> +  capability sys_admin,
> +  capability sys_module,
> +  capability sys_ptrace,
> +  capability sys_nice,
> +  capability sys_chroot,
> +  capability setuid,
> +  capability dac_override,
> +  capability dac_read_search,
> +  capability fowner,
> +  capability chown,
> +  capability setpcap,
> +  capability mknod,
> +  capability fsetid,
> +  capability ipc_lock,
> +  capability audit_write,
> +
> +  network inet stream,
> +  network inet dgram,
> +  network inet6 stream,
> +  network inet6 dgram,
> +  network packet dgram,
> +
> +  # for now, use a very lenient profile since we want to first focus on
> +  # confining the guests
> +  / r,
> +  /** rwmkl,
> +
> +  /bin/* PUx,
> +  /sbin/* PUx,
> +  /usr/bin/* PUx,
> +  /usr/sbin/* PUx,
> +  /lib/udev/scsi_id PUx,
> +  /usr/lib/xen-common/bin/xen-toolstack 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,
> +  audit deny /etc/apparmor.d/libvirt/** wxl,
> +  audit deny /sys/kernel/security/apparmor/features rwxl,
> +  audit deny /sys/kernel/security/apparmor/matching rwxl,
> +  audit deny /sys/kernel/security/apparmor/.* rwxl,
> +  /sys/kernel/security/apparmor/profiles r,
> +  /usr/lib/libvirt/* PUxr,
> +  /etc/libvirt/hooks/** rmix,
> +  /etc/xen/scripts/** rmix,
> +
> +  # allow changing to our UUID-based named profiles
> +  change_profile -> @{LIBVIRT}-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*,
> +
> +}
> diff -Nru libvirt-1.2.0/debian/control libvirt-1.2.0/debian/control
> --- libvirt-1.2.0/debian/control	2013-12-28 11:30:35.000000000 +0100
> +++ libvirt-1.2.0/debian/control	2014-01-03 20:51:20.000000000 +0100
> @@ -37,6 +37,7 @@
>   libsanlock-dev [linux-any],
>   libaudit-dev [linux-any],
>   libselinux1-dev (>= 2.0.82) [linux-any],
> + libapparmor-dev [linux-any],
>   systemtap-sdt-dev [amd64 armel armhf i386 ia64 powerpc s390],
>  # for --with-storage-sheepdog
>   sheepdog [linux-any],
> @@ -76,7 +77,7 @@
>   iproute,
>   parted,
>   pm-utils
> -Suggests: policykit-1, radvd, auditd, systemtap, systemd
> +Suggests: policykit-1, radvd, auditd, systemtap, systemd, apparmor
>  Breaks: avahi-daemon (<< 0.6.31-3~)
>  Description: programs for the libvirt library
>   Libvirt is a C toolkit to interact with the virtualization capabilities
> diff -Nru libvirt-1.2.0/debian/libvirt-bin.cron.daily libvirt-1.2.0/debian/libvirt-bin.cron.daily
> --- libvirt-1.2.0/debian/libvirt-bin.cron.daily	1970-01-01 01:00:00.000000000 +0100
> +++ libvirt-1.2.0/debian/libvirt-bin.cron.daily	2012-12-05 23:37:34.000000000 +0100
> @@ -0,0 +1,38 @@
> +#!/bin/sh
> +#
> +# clean out AppArmor profiles for virtual machines that no longer exist
> +#
> +set -e
> +
> +PROFILES_DIR="/etc/apparmor.d/libvirt"
> +AA_PROFILES="/sys/kernel/security/apparmor/profiles"
> +
> +uuids=""
> +remove_if_unused() {
> +    uuid=`basename "$1" | sed 's/libvirt-//' | egrep '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'` || return
> +
> +    # don't remove a profile for an existing VM
> +    echo "$uuids" | grep -q "$uuid" && return
> +
> +    # don't remove a loaded profile
> +    if [ -e "$AA_PROFILES" ] && grep -q "$uuid" "$AA_PROFILES" ; then
> +        return
> +    fi
> +
> +    find $PROFILES_DIR -name "libvirt-${uuid}*" -prune -type f -exec rm -f -- '{}' \;
> +}
> +
> +# read in all existing uuids
> +for i in /etc/libvirt/qemu/*.xml ; do
> +    if [ -r "$i" ]; then
> +        uuid=`grep '<uuid>' "$i" | sed 's#.*<uuid>\(.*\)</uuid>.*#\1#'`
> +        uuids="$uuids $uuid"
> +    fi
> +done
> +
> +for i in "$PROFILES_DIR"/libvirt-* ; do
> +    if [ -r "$i" ]; then
> +        basename "$i" | egrep -q '\.' && continue
> +        remove_if_unused "$i" || true
> +    fi
> +done
> diff -Nru libvirt-1.2.0/debian/libvirt-bin.postinst libvirt-1.2.0/debian/libvirt-bin.postinst
> --- libvirt-1.2.0/debian/libvirt-bin.postinst	2013-12-17 23:14:46.000000000 +0100
> +++ libvirt-1.2.0/debian/libvirt-bin.postinst	2014-01-03 19:08:53.000000000 +0100
> @@ -123,6 +123,13 @@
>  	for dir in qemu uml lxc; do
>  	    touch /var/log/libvirt/"${dir}"/.placeholder
>  	done
> +
> +    for p in usr.sbin.libvirtd usr.lib.libvirt.virt-aa-helper ; do
> +        profile="/etc/apparmor.d/$p"
> +        if [ -f "$profile" ] && aa-status --enabled 2>/dev/null; then
> +            apparmor_parser -r "$profile" || true
> +        fi
> +    done
>      ;;
>  
>      abort-upgrade|abort-remove|abort-deconfigure)
> diff -Nru libvirt-1.2.0/debian/libvirt-bin.postrm libvirt-1.2.0/debian/libvirt-bin.postrm
> --- libvirt-1.2.0/debian/libvirt-bin.postrm	2013-12-17 23:14:46.000000000 +0100
> +++ libvirt-1.2.0/debian/libvirt-bin.postrm	2014-01-03 16:57:29.000000000 +0100
> @@ -34,6 +34,11 @@
>  	fi
>  
>  	rm -rf /var/log/libvirt
> +
> +	for f in usr.sbin.libvirtd usr.lib.libvirt.virt-aa-helper ; do
> +		rm -f /etc/apparmor.d/force-complain/$f >/dev/null 2>&1 || true
> +		rm -f /etc/apparmor.d/disable/$f >/dev/null 2>&1 || true
> +	done
>      ;;
>      remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
>      ;;
> diff -Nru libvirt-1.2.0/debian/rules libvirt-1.2.0/debian/rules
> --- libvirt-1.2.0/debian/rules	2013-12-28 11:27:15.000000000 +0100
> +++ libvirt-1.2.0/debian/rules	2014-01-03 20:53:21.000000000 +0100
> @@ -30,6 +30,7 @@
>    WITH_INIT_SCRIPT    =	--with-init-script=systemd
>    WITH_AUDIT          = --with-audit
>    WITH_SELINUX        = --with-selinux --with-secdriver-selinux
> +  WITH_APPARMOR       = --with-apparmor --with-secdriver-apparmor
>    ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 armel armhf i386 ia64 powerpc s390))
>        WITH_DTRACE     = --with-dtrace
>    else
> @@ -63,6 +64,7 @@
>    WITH_INIT_SCRIPT    =	--with-init-script=none
>    WITH_AUDIT          = --without-audit
>    WITH_SELINUX        = --without-selinux
> +  WITH_APPARMOR       = --without-apparmor
>    WITH_DTRACE         = --without-dtrace
>    WITH_XEN            = --without-xen
>    WITH_LIBXL          = --without-libxl
> @@ -91,6 +93,7 @@
>  	$(WITH_INIT_SCRIPT)      \
>  	$(WITH_NUMA)             \
>  	$(WITH_SELINUX)          \
> +	$(WITH_APPARMOR)         \
>  	--without-esx		 \
>  	--without-phyp           \
>  	$(WITH_CAPNG)		 \
> @@ -110,6 +113,8 @@
>  LOGROTATE = $(basename $(basename $(notdir $(wildcard daemon/libvirtd*.logrotate.in))))
>  EXAMPLES_DIR = $(CURDIR)/debian/libvirt-doc/usr/share/doc/libvirt-doc/examples/
>  
> +DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
> +
>  %:
>  	dh $@ --builddirectory=$(DEB_BUILDDIR)
>  
> @@ -150,6 +155,17 @@
>  	# Don't ship api files in the daemon package
>  	rm -r debian/libvirt-bin/usr/share/libvirt/api/
>  
> +ifeq ($(DEB_HOST_ARCH_OS),linux)
> +	cp debian/tmp/usr/lib/libvirt/virt-aa-helper debian/libvirt-bin/usr/lib/libvirt
> +	mkdir -p debian/libvirt-bin/etc/apparmor.d/abstractions debian/libvirt-bin/etc/apparmor.d/libvirt
> +	mkdir -p debian/libvirt-bin/etc/apparmor.d/local
> +	cp debian/apparmor/libvirt-qemu debian/libvirt-bin/etc/apparmor.d/abstractions
> +	cp debian/apparmor/usr.lib.libvirt.virt-aa-helper debian/libvirt-bin/etc/apparmor.d
> +	cp debian/apparmor/usr.sbin.libvirtd debian/libvirt-bin/etc/apparmor.d
> +	cp debian/apparmor/local-usr.sbin.libvirtd debian/libvirt-bin/etc/apparmor.d/local/usr.sbin.libvirtd
> +	cp debian/apparmor/TEMPLATE debian/libvirt-bin/etc/apparmor.d/libvirt
> +endif
> +
>  override_dh_installinit:
>  	dh_systemd_enable
>  	dh_installinit --name=libvirt-bin --no-restart-on-upgrade -- defaults 28 72

> _______________________________________________
> Pkg-libvirt-maintainers mailing list
> Pkg-libvirt-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Message #35 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Felix Geyer <fgeyer@debian.org>

To: Guido Günther <agx@sigxcpu.org>

Cc: 725144@bugs.debian.org, Ben Kibbey <bjk@luxsci.net>

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Sat, 04 Jan 2014 20:03:14 +0100

Hi,

On 04.01.2014 18:19, Guido Günther wrote:
> Hi Felix,
> On Fri, Jan 03, 2014 at 10:58:14PM +0100, Felix Geyer wrote:
>> I've ported and tested the libvirt AppArmor support from the Ubuntu package.
>>
>> The only difference in the profiles is this addition to usr.lib.libvirt.virt-aa-helper:
>>   /etc/libnl-[0-9]/classid r,
>>
>> It can be enabled by setting this in /etc/libvirt/qemu.conf:
>> security_driver = "apparmor"
> 
> Can you please work on upsreaming this? I don't see why this should be
> in the Debian package. Who is going to maintain this policies in the
> future?
> Cheers,
>  -- Guido

The upstream source already contains example profiles. It's generally not feasible to
maintain AppArmor profiles upstream because of distro differences and changes.

The profiles usr.sbin.libvirtd and usr.lib.libvirt.virt-aa-helper could be easily
maintained in a separate apparmor profile package. intrigeri proposed a
apparmor-profiles-extra package [1] that would be maintained by an AppArmor Debian team.
I am committed to maintain the libvirt profiles.

Having libvirt-qemu outside of libvirt is problematic because the AppArmor driver of
libvirt uses it to generate profiles for the VMs. When it's missing starting VMs will
fail (when the AppArmor driver is enabled).

Cheers,
Felix

[1] https://lists.ubuntu.com/archives/apparmor/2014-January/004876.html

Message #40 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Felix Geyer <fgeyer@debian.org>

Cc: 725144@bugs.debian.org, Ben Kibbey <bjk@luxsci.net>

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Tue, 7 Jan 2014 17:18:26 +0100

Hi Felix,
On Sat, Jan 04, 2014 at 08:03:14PM +0100, Felix Geyer wrote:
> Hi,
> 
> On 04.01.2014 18:19, Guido Günther wrote:
> > Hi Felix,
> > On Fri, Jan 03, 2014 at 10:58:14PM +0100, Felix Geyer wrote:
> >> I've ported and tested the libvirt AppArmor support from the Ubuntu package.
> >>
> >> The only difference in the profiles is this addition to usr.lib.libvirt.virt-aa-helper:
> >>   /etc/libnl-[0-9]/classid r,
> >>
> >> It can be enabled by setting this in /etc/libvirt/qemu.conf:
> >> security_driver = "apparmor"
> > 
> > Can you please work on upsreaming this? I don't see why this should be
> > in the Debian package. Who is going to maintain this policies in the
> > future?
> > Cheers,
> >  -- Guido
> 
> The upstream source already contains example profiles. It's generally not feasible to
> maintain AppArmor profiles upstream because of distro differences and changes.

We should at least maintain the common parts upstream then. The include
mechanism could cater for distro specific changes. We could also
preprocess these files during build time to fixup path differences like
we do for init scripts and other stuff already. Additinoally we can use
a diff against the upstream example. All is better than doing this all
by hand.

I'd be happy to help with that given that your patient enough with me
being a apparmor newbie. If looked at the profiles in a bit more detail:

* libvirt-qemu - this file has several additions that aren't needed for
  Debian, the upstream file could be adopted with minimal additions
* TEMPLATE: 100% identical
* usr.lib.libvirt.virt-aa-helper This file has several additions which
  puzzle me - we do allow access to images _and_ certain directories.
  isn't the former enough?
* usr.sbin.libvirtd minimal differences suitable upstream

> The profiles usr.sbin.libvirtd and usr.lib.libvirt.virt-aa-helper could be easily
> maintained in a separate apparmor profile package. intrigeri proposed a
> apparmor-profiles-extra package [1] that would be maintained by an AppArmor Debian team.
> I am committed to maintain the libvirt profiles.

Great! I'd still prefer if this would happen upstream but that's totally
your decision as maintainer of the profiles. See above.

> Having libvirt-qemu outside of libvirt is problematic because the AppArmor driver of
> libvirt uses it to generate profiles for the VMs. When it's missing starting VMs will
> fail (when the AppArmor driver is enabled).

That seems to happen in virt-aa-helper in create_profile. It looks as it
wouldn't matter if libvirt-qemu is in libvirt-bin or a separate profile
package. In case we find security_driver = "apparmor" in qemu.conf we
could just error out if the (suggested by libvirt-bin) profile package
isn't installed.

Would it already help if we build in apparmor support but don't ship any
profiles until this is sorted out?

Cheers,
 -- Guido

> 
> Cheers,
> Felix
> 
> [1] https://lists.ubuntu.com/archives/apparmor/2014-January/004876.html
> 

Message #45 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: libvir-list@redhat.com

Subject: [PATCH] Allow to install apparmor profiles

Date: Tue, 7 Jan 2014 17:19:36 +0100

Make it easy to install the shipped examples. The aim is to have
reasonably working templates so that distros only need to minimally
patch these and can feed things upstream more easily.

This was prompted by http://bugs.debian.org/725144
---
 configure.ac                  | 12 +++++++++++-
 examples/apparmor/Makefile.am | 18 ++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 2622dfd..97752f4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1418,6 +1418,16 @@ elif test "with_secdriver_apparmor" != "no" ; then
 fi
 AM_CONDITIONAL([WITH_SECDRIVER_APPARMOR], [test "$with_secdriver_apparmor" != "no"])
 
+if test "$with_apparmor" != "no"; then
+AC_ARG_WITH([apparmor-profiles],
+  [AS_HELP_STRING([--with-apparmor-profiles],
+    [install apparmor profiles @<:@default=no@:>@])],
+  [with_apparmor_profiles=yes],
+  [with_apparmor_profiles=no])
+else
+  with_apparmor_profiles="no"
+fi
+AM_CONDITIONAL([WITH_APPARMOR_PROFILES], [test "$with_apparmor_profiles" != "no"])
 
 dnl DTrace static probes
 AC_ARG_WITH([dtrace],
@@ -2607,7 +2617,7 @@ AC_MSG_NOTICE([])
 AC_MSG_NOTICE([Security Drivers])
 AC_MSG_NOTICE([])
 AC_MSG_NOTICE([ SELinux: $with_secdriver_selinux ($SELINUX_MOUNT)])
-AC_MSG_NOTICE([AppArmor: $with_secdriver_apparmor])
+AC_MSG_NOTICE([AppArmor: $with_secdriver_apparmor (install profiles: $with_apparmor_profiles)])
 AC_MSG_NOTICE([])
 AC_MSG_NOTICE([Driver Loadable Modules])
 AC_MSG_NOTICE([])
diff --git a/examples/apparmor/Makefile.am b/examples/apparmor/Makefile.am
index 79cf5c9..6e69440 100644
--- a/examples/apparmor/Makefile.am
+++ b/examples/apparmor/Makefile.am
@@ -19,3 +19,21 @@ EXTRA_DIST=				\
 	libvirt-qemu			\
 	usr.lib.libvirt.virt-aa-helper	\
 	usr.sbin.libvirtd
+
+if WITH_APPARMOR_PROFILES
+apparmordir = $(sysconfdir)/apparmor.d/
+apparmor_DATA = \
+	usr.lib.libvirt.virt-aa-helper \
+	usr.sbin.libvirtd \
+	$(NULL)
+
+abstractionsdir = $(apparmordir)/abstractions
+abstractions_DATA = \
+	libvirt-qemu \
+	$(NULL)
+
+templatesdir = $(apparmordir)/libvirtd
+templates_DATA = \
+	TEMPLATE \
+	$(NULL)
+endif WITH_APPARMOR_PROFILES
-- 
1.8.5.1

Message #50 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Felix Geyer <fgeyer@debian.org>

To: Guido Günther <agx@sigxcpu.org>

Cc: 725144@bugs.debian.org

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Tue, 21 Jan 2014 23:04:06 +0100

Hi,

On 07.01.2014 17:18, Guido Günther wrote:
> We should at least maintain the common parts upstream then. The include
> mechanism could cater for distro specific changes. We could also
> preprocess these files during build time to fixup path differences like
> we do for init scripts and other stuff already. Additinoally we can use
> a diff against the upstream example. All is better than doing this all
> by hand.
> 
> I'd be happy to help with that given that your patient enough with me
> being a apparmor newbie. If looked at the profiles in a bit more detail:
> 
> * libvirt-qemu - this file has several additions that aren't needed for
>   Debian, the upstream file could be adopted with minimal additions
> * TEMPLATE: 100% identical
> * usr.lib.libvirt.virt-aa-helper This file has several additions which
>   puzzle me - we do allow access to images _and_ certain directories.
>   isn't the former enough?

No, "/path/** r" doesn't give you access to /path/, so I think stat, readdir, etc.
on /path are not allowed.

> * usr.sbin.libvirtd minimal differences suitable upstream

I'll have a more detailed look at the differences between the upstream and
Ubuntu profiles tomorrow to see which parts are upstreamable.
Would you accept a patch with the necessary profile changes in the meantime?
The policies shipped by upstream don't work as they are right now (starting VMs fails).

>> The profiles usr.sbin.libvirtd and usr.lib.libvirt.virt-aa-helper could be easily
>> maintained in a separate apparmor profile package. intrigeri proposed a
>> apparmor-profiles-extra package [1] that would be maintained by an AppArmor Debian team.
>> I am committed to maintain the libvirt profiles.
> 
> Great! I'd still prefer if this would happen upstream but that's totally
> your decision as maintainer of the profiles. See above.
> 
>> Having libvirt-qemu outside of libvirt is problematic because the AppArmor driver of
>> libvirt uses it to generate profiles for the VMs. When it's missing starting VMs will
>> fail (when the AppArmor driver is enabled).
> 
> That seems to happen in virt-aa-helper in create_profile. It looks as it
> wouldn't matter if libvirt-qemu is in libvirt-bin or a separate profile
> package. In case we find security_driver = "apparmor" in qemu.conf we
> could just error out if the (suggested by libvirt-bin) profile package
> isn't installed.
> 
> Would it already help if we build in apparmor support but don't ship any
> profiles until this is sorted out?

I was wrong about when the apparmor driver is enabled:
It's automatically enabled when /usr/sbin/libvirtd has an apparmor profile attached to it
and /etc/apparmor.d/libvirt/TEMPLATE exists. There's no need to enable it in the config.

So it would be feasible to maintain the profiles in a separate package. Personally I'd
prefer to ship them in libvirt since it requires some integration work and is not just
a profile that you stick into /etc/apparmor.d/.

I see you've already enabled the apparmor driver but the required binary
/usr/lib/libvirt/virt-aa-helper is not installed into libvirt-bin.
The postinst, postrm and cron.daily parts of my original patch are also desirable.
For example without the postinst changes the profiles are only loaded after a reboot.

Cheers,
Felix

Message #55 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Felix Geyer <fgeyer@debian.org>

Cc: 725144@bugs.debian.org

Subject: Re: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Wed, 22 Jan 2014 07:27:21 +0100

Hi Felix,
On Tue, Jan 21, 2014 at 11:04:06PM +0100, Felix Geyer wrote:
[..snip..] 
> I'll have a more detailed look at the differences between the upstream and
> Ubuntu profiles tomorrow to see which parts are upstreamable.
> Would you accept a patch with the necessary profile changes in the meantime?
> The policies shipped by upstream don't work as they are right now (starting VMs fails).

I'm fine with a patch against a libvirt built with
--with-apparmor-profiles (which I we added upstream to ease basing
profiles on the upstream work). This will allow us to upstream profile
changes as necessary and avoid lots of unnecessary duplictaion. Please
already remove the Ubuntu specific parts like the encfs stuff among
other things.

[..snip..] 
> I was wrong about when the apparmor driver is enabled:
> It's automatically enabled when /usr/sbin/libvirtd has an apparmor profile attached to it
> and /etc/apparmor.d/libvirt/TEMPLATE exists. There's no need to enable it in the config.

That's what I read from the sources however for libvird but I'm haven't
checked yet if you need to enable it for qemu vm confinement.

> So it would be feasible to maintain the profiles in a separate package. Personally I'd
> prefer to ship them in libvirt since it requires some integration work and is not just
> a profile that you stick into /etc/apparmor.d/.

I'm fine with shipping it if we try to minimize the diff. 

> I see you've already enabled the apparmor driver but the required binary
> /usr/lib/libvirt/virt-aa-helper is not installed into libvirt-bin.

I meant to include this too. An oversight on my part.

> The postinst, postrm and cron.daily parts of my original patch are also desirable.
> For example without the postinst changes the profiles are only loaded after a reboot.

The whole setup currently has the problem that it doesn't allow for a
read only /etc and that it removes files out of /etc/ which can confuse
users. The generated profiles shouldn't life in /etc but in
/var/cache/libvirt/apparmor. Once this is moved we can clean the up. Can
you fix that up (e.g. by a symlink).

The postinst part is fine but we should move tha aa-status call out of
the loop. No need to do it several times:

if aa-status --enabled 2>/dev/null; then
  ....
fi

Thanks for working on this!
Cheers,
 -- Guido

Message #60 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Felix Geyer <fgeyer@debian.org>

To: Guido Günther <agx@sigxcpu.org>, 725144@bugs.debian.org

Cc: Jamie Strandboge <jamie@canonical.com>

Subject: Re: Bug#725144: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Thu, 30 Jan 2014 20:26:29 +0100

On 22.01.2014 07:27, Guido Günther wrote:
>> > The postinst, postrm and cron.daily parts of my original patch are also desirable.
>> > For example without the postinst changes the profiles are only loaded after a reboot.
> The whole setup currently has the problem that it doesn't allow for a
> read only /etc and that it removes files out of /etc/ which can confuse
> users. The generated profiles shouldn't life in /etc but in
> /var/cache/libvirt/apparmor. Once this is moved we can clean the up. Can
> you fix that up (e.g. by a symlink).

virsh also removes the VM definition file from /etc/libvirt/qemu/ so I don't see
how this is different.

libvirt generates 2 AppArmor profile files:
- libvirt-<UUID>: auto-generated once, then user-modifiable
- libvirt-<UUID>.files: auto-generated, automatically regenerated

The first one should actually live in /etc, the second one could be moved to /var/cache.
I'm not a huge fan of having both files in different directories though.
Jamie, what do you think about this?


> The postinst part is fine but we should move tha aa-status call out of
> the loop. No need to do it several times:
> 
> if aa-status --enabled 2>/dev/null; then
>   ....
> fi

Ok, will fix that.

Regards,
Felix

Message #65 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Jamie Strandboge <jamie@canonical.com>

To: Felix Geyer <fgeyer@debian.org>, Guido Günther <agx@sigxcpu.org>, 725144@bugs.debian.org

Subject: Re: Bug#725144: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Thu, 30 Jan 2014 13:46:38 -0600

[Message part 1 (text/plain, inline)]

On 01/30/2014 01:26 PM, Felix Geyer wrote:
> On 22.01.2014 07:27, Guido Günther wrote:
>>>> The postinst, postrm and cron.daily parts of my original patch are also desirable.
>>>> For example without the postinst changes the profiles are only loaded after a reboot.
>> The whole setup currently has the problem that it doesn't allow for a
>> read only /etc and that it removes files out of /etc/ which can confuse
>> users. The generated profiles shouldn't life in /etc but in
>> /var/cache/libvirt/apparmor. Once this is moved we can clean the up. Can
>> you fix that up (e.g. by a symlink).
> 
> virsh also removes the VM definition file from /etc/libvirt/qemu/ so I don't see
> how this is different.
> 
> libvirt generates 2 AppArmor profile files:
> - libvirt-<UUID>: auto-generated once, then user-modifiable
> - libvirt-<UUID>.files: auto-generated, automatically regenerated
> 
> The first one should actually live in /etc, the second one could be moved to /var/cache.
> I'm not a huge fan of having both files in different directories though.
> Jamie, what do you think about this?
> 

I agree that it is awkward to have them in different places, which is why it is
the way it is now (and has been this way upstream and in Ubuntu for years--
which isn't a point to not fix things, just saying it isn't a new problem).
libvirt will fail to function with a readonly /etc for vm definitions and
networks at least so it would seem weird to fix this but not everything else.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

[signature.asc (application/pgp-signature, attachment)]

Message #70 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Jamie Strandboge <jamie@canonical.com>

Cc: Felix Geyer <fgeyer@debian.org>, 725144@bugs.debian.org

Subject: Re: Bug#725144: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Thu, 30 Jan 2014 21:38:54 +0100

On Thu, Jan 30, 2014 at 01:46:38PM -0600, Jamie Strandboge wrote:
> On 01/30/2014 01:26 PM, Felix Geyer wrote:
> > On 22.01.2014 07:27, Guido Günther wrote:

[..snip..] 

> I agree that it is awkward to have them in different places, which is why it is
> the way it is now (and has been this way upstream and in Ubuntu for years--
> which isn't a point to not fix things, just saying it isn't a new problem).
> libvirt will fail to function with a readonly /etc for vm definitions and
> networks at least so it would seem weird to fix this but not everything else.

Everything else should be fixed up too of course. We had a hard time
having a ro /etc and this would actively work against it. Since the
default storage pool is on /var too I don't think we won't run into any
issues of /var not being available early enough. I also think symlinks
are fine to start with.
Cheers,
 -- Guido

Message #75 received at 725144@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Felix Geyer <fgeyer@debian.org>

Cc: 725144@bugs.debian.org, Jamie Strandboge <jamie@canonical.com>

Subject: Re: Bug#725144: [Pkg-libvirt-maintainers] Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Thu, 30 Jan 2014 21:40:52 +0100

On Thu, Jan 30, 2014 at 08:26:29PM +0100, Felix Geyer wrote:
> On 22.01.2014 07:27, Guido Günther wrote:
> >> > The postinst, postrm and cron.daily parts of my original patch are also desirable.
> >> > For example without the postinst changes the profiles are only loaded after a reboot.
> > The whole setup currently has the problem that it doesn't allow for a
> > read only /etc and that it removes files out of /etc/ which can confuse
> > users. The generated profiles shouldn't life in /etc but in
> > /var/cache/libvirt/apparmor. Once this is moved we can clean the up. Can
> > you fix that up (e.g. by a symlink).
> 
> virsh also removes the VM definition file from /etc/libvirt/qemu/ so I don't see
> how this is different.

Virsh does this on user _request_ - just like fiering up an editor.

> 
> libvirt generates 2 AppArmor profile files:
> - libvirt-<UUID>: auto-generated once, then user-modifiable
> - libvirt-<UUID>.files: auto-generated, automatically regenerated
> 
> The first one should actually live in /etc, the second one could be moved to /var/cache.
> I'm not a huge fan of having both files in different directories though.
> Jamie, what do you think about this?

Yeah. That's fine. the first one looks more like it should be handled
like a conf file then so it's fine for /etc/.
Cheers,
 -- Guido

Message #80 received at 725144@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 725144@bugs.debian.org

Subject: Re: Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Tue, 29 Jul 2014 13:37:10 +0200

Hi,

AppArmor support works fine on current sid. Seems to have been the
case since 1.2.1-2, and refined later for non-Linux. Shall we close
this bug?

Cheers,
--
intrigeri

Message #85 received at 725144-done@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: intrigeri <intrigeri@debian.org>, 725144-done@bugs.debian.org

Subject: Re: Bug#725144: libvirt-bin: Please build with apparmor support.

Date: Tue, 29 Jul 2014 13:57:27 +0200

Version: 1.2.4-3

On Tue, Jul 29, 2014 at 01:37:10PM +0200, intrigeri wrote:
> Hi,
> 
> AppArmor support works fine on current sid. Seems to have been the
> case since 1.2.1-2, and refined later for non-Linux. Shall we close
> this bug?

Great. Thank's for reporting back!
 -- Guido

Send a report that this bug log contains spam.