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 > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
