[apparmor] Condition rules on apparmor version

[John Johansen]

On 06/27/2014 04:23 PM, Jeroen Ooms wrote:
> I am trying to make an apparmor profile that will both work on Debian
> Wheezy (2.7.103-4) as well as Ubuntu trusty (2.8.95).
> 
this is difficult atm

> The application uses two profiles: opencpu-main [1] and
> opencpu-exec[2]. A process confined by opencpu-main has to be able to
> kill a process confined by opencpu-exec. Up till apparmor 2.8.0 this
> was unregulated, hence no special rules are needed to allow the
> killing on Debian. However starting apparmor 2.8.95, the profile needs
> to contain the following rules in order for this to be permitted:
> 
> In opencpu-main:
>   signal w peer=opencpu-exec,
> 
> In opencpu-exec:
>   signal r peer=opencpu-main,
> 
> With these rules added to the profile, the application works in
> Trusty. However in Debian I get a syntax error with these rules
> because the signal functionality is not available yet. So I now need
> to maintain separate profiles on my Debian and Ubuntu boxes, which is
> a bit inconvenient.
> 
yes very inconvenient

> So the question: is there some way to define this permission using a
> rule that will work for both versions of apparmor? A line that permits
> opencpu-main to kill opencpu-exec in apparmor 2.8.95, but gets ignored
> or is harmless in apparmor 2.7.103?
> 
so uhm yes and no.

There is what I would call a work-around that will let you use it with
only a minor tweak, however it won't work out of the box because no
one is shipping tunables that define distribution nor available feature
set.

Basically you can either wrap the rule in a conditional

if $somevar = foo {
  signal r peer=opencpu-main,
}

then you need to define that var, either at the top of the profile or in
an include. And at this point the question is, why isn't there a distro
variable already defined in shipping policy? Sadly there isn't but
at least doing this you could define your own include and tweak the
variable in one place to get your profiles to work.

If you could install the newer ubuntu parser on debian, things would just
work as it knows whether the kernel supports the new rules and can drop
them.

Going forward we have a work item to fix this problem this cycle. Though
it will take a few releases to have it percolate out to the different
distros and be universally available.

To solve this we will be using a combination of techniques. Defining
some basic tunables like distro, and distro_version, exporting the
kernel supported feature set from the parser so the policy can be
conditional on it. Adding a template system so that an older parser
can identify and properly skip new rules it doesn't understand.

Ideally most of the details will be hidden in includes, so that
a profile can just specify an include for the policy version it
supports, and then things just magically work.

We really want to avoid profiles being filled with conditional
statements.