On 01.10.2014 11:04, 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 ?
The way release are handled in Ubuntu (once released there is usually no backporting) we would have to worry less about supported releases. For the Debian side I would think this is similar (correct me if I am wrong, please). So it looks to me that right now this would be down to Debian having 2.8.0 in unstable/testing and Ubuntu having 2.8.96~2652 in Utopic (with the same version in Debian experimental). Right now I would expect it to boil down to those two. But I suppose the parser can change again and so there might be a similar situation in the future. -Stefan
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.
Regards, Daniel