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

[Guido Günther]

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
>