On Wed, Oct 01, 2014 at 09:46:08AM -0500, Jamie Strandboge wrote: > On 10/01/2014 04:04 AM, Daniel P. Berrange wrote: > > On Wed, Oct 01, 2014 at 10:30:58AM +0200, Stefan Bader wrote: > >> This had been on the Debian package list before but its time to take > >> this onwards. So the goal would be to have one set to rule them all > >> (when using apparmor) and drop the seperate set of definitions which > >> exist at least in the Ubuntu packaging. > >> > >> Right now the patch would be at a state which adds all missing files > >> and rules to the current examples in libvirt and installs them when > >> using --with-apparmor-profiles. > >> > >> One problem seems to be that some of the definitions might cause > >> parse failures on certain versions of apparmor. I checked this morning > >> and this looks a bit hairy. So some apparmor 2.8 versions potentially > >> have issues, but not all apparmor 2.8 are the same (gah). > > > > What versions of apparmour are present in the currently supported > > versions of Debian & Ubuntu ? > > > >> I could imagine (but John, we really could use some guidance here ;)) > >> that at least some changes could be related to version 2.8.95~2430: > >> > >> + debian/patches/mediate-signals.patch, > >> debian/patches/change-signal-syntax.patch: Parse signal rules with > >> apparmor_parser. See the apparmor.d(5) man page for syntax details. > >> + debian/patches/change-ptrace-syntax.patch, > >> debian/patches/mediate-ptrace.patch: Parse ptrace rules with > >> apparmor_parser. See the apparmor.d(5) man page for syntax details. > >> > >> But, regardless of the when, the apparmor rules maybe need a way to handle > >> versioned features of the parser. One proposal was to comment out problematic > >> rules and allow the packager to re-enable things. Maybe going one step > >> further and have some pre-processing that handles version based sections > >> (like #if (APPARMOR_VERSION >= xxx)). > > > > I think it would be pretty reasonable to rename the files in have '.in' > > suffixes, and then have a build script that expands 'if APPARMOR_VERSION' > > conditionals to generate the final file. > > > These are the rules that are problematic: dbus, ptrace, signal and unix. All of > these are not part of upstream apparmor 2.8 proper, but are part of the upcoming > 2.9 release. Ubuntu is using prereleases of upstream apparmor 2.9 where 2.8.95 > has dbus, ptrace and signal rules and 2.8.96 adds unix rules (unfortunately, > Ubuntu introduced dbus rules as a patch on top of apparmor 2.8.0 in > 2.8.0-0ubuntu25 for Ubuntu 13.10-- however, Ubuntu 13.10 is EOL now so I think > it is fine to not consider this). > > If we were to decide to adjust the rules based on apparmor version, then please > add dbus, ptrace, signal and unix rules based on APPARMOR_VERSION >= 2.9. > Distributions like Ubuntu using a prerelease version of AppArmor can then choose > to adjust the APPARMOR_VERSION check. IIUC Debian and SUSE will continue to use > use official 2.8 until 2.9 becomes official[1]. Agreed, the libvirt upstream distributed file should do version checks based on official apparmor releases, and distros can tweak versions if they have backported features. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list