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