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

[Felix Geyer]

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