support conditional include directives

[Patrick Schleizer]

This is a small usability issue. Testing of AppArmor profiles could be a bit simpler, if users could just drop a AppArmor profile in /etc/apparmor.d/.

The problem is, some(most?) AppArmor scripts include a "#include <local/usr.bin...>" line and the AppArmor profile will fail to load, if "local/usr.bin..." does not exist. Being more opportunistic would be better, i.e. if "local/usr.bin..." exists, source it, otherwise don't fail.

[intrigeri (intrigeri)]

As discussed on https://lists.ubuntu.com/archives/apparmor/2017-November/011335.html, this would also avoid packages shipping empty or boilerplate-only files in /etc/apparmor.d/local/.

[intrigeri (intrigeri)]

Another use case would be nicer support for per-profile tunables file, to ease local customization of profiles: https://lists.ubuntu.com/archives/apparmor/2017-December/011359.html. But this may cause trouble elsewhere: https://bugs.launchpad.net/apparmor/+bug/1331856.

[intrigeri (intrigeri)]

https://gitlab.com/apparmor/apparmor/merge_requests/51

[Vincas Dargis (talkless)]

Very cool! It's happening faster than I was expecting.

[intrigeri (intrigeri)]

This was merged (https://gitlab.com/apparmor/apparmor/-/merge_requests/51) into v2.13 and backported to v2.10.4, v2.11.2, and v2.12.1.

Can we now close this issue? If not, what's left to do here?

[Christian Boltz (cboltz)]

Yes, we can close this ancient issue ;-)

Note: the aa-* tools (aa-logprof etc.) in 2.x will error out if they hit "include if exists" (and interpret "#include if exists" as a comment). This is fixed in 3.x, but unfortunately it's a big patch that can't be easily backported.