[apparmor] RFC: using variables to make profiles more flexible

[Vincas Dargis]

Hi,

There is a Thunderbird bug [0] about profile not allowing to read `.thunderbird` for outside of $HOME.

Currently, Thunderbird profile [1] has quite a few rules for `.thunderbird`:

```
   # per-user thunderbird configuration
   owner @{HOME}/.{icedove,thunderbird}/ rw,
   owner @{HOME}/.{icedove,thunderbird}/** rw,
   owner @{HOME}/.{icedove,thunderbird}/**/storage.sdb k,
   owner @{HOME}/.{icedove,thunderbird}/**/*.{db,parentlock,sqlite}* k,
   owner @{HOME}/.{icedove,thunderbird}/plugins/** rm,
   owner @{HOME}/.{icedove,thunderbird}/**/plugins/** rm,

```

To ask for a user to copy-and-modify these into `local/usr.bin.thunderbird` with modified paths is kinda.. not nice, and 
not really future-compatible, if some new rules would be added.

I think it would be useful for these kind of profiles to have variables, in this case:

```
@{thunderbird_profile_dirs} = @{HOME}
```

I've seen this idea in the Libreoffice profile. It has quite a few variables [2], like this one:

```
@{libo_user_dirs} = @{HOME} /mnt /media
```

But how would user extend these variables? The `man apparmor.d` states that, if I understood correctly, that variables 
has to be defined before profile starts [3], so `local/usr.bin.foo` includes does not help, and modifying main profile 
is IMHO really not good, as it will be overwritten after package upgrade (or asked to diff/merge/whatever) , so next 
target are "tunables" includes.

Libreoffice profile (as others too) has this include before start of main profile:

```
#include <tunables/global>
```

`tunables/global` later includes these variable-specific files:

```
#include <tunables/home>
#include <tunables/multiarch>
#include <tunables/proc>
#include <tunables/alias>
#include <tunables/kernelvars>
#include <tunables/xdg-user-dirs>
```

I don't see "dedicated" place for overriding/extending other profile-custom variables, such as `@{libo_user_dirs}` for 
example.

Maybe it would be useful to have specific per-profile tuntables, so in Thunderbird's case it look like this:

```
@{thunderbird_profile_dirs} = @{HOME}

#include <tunables/global>
#include <tunables/usr.bin.thunderbird.d>

profile ... {
   # ...
   owner @{thunderbird_profile_dirs}/.{icedove,thunderbird}/ rw,
   owner @{thunderbird_profile_dirs}/.{icedove,thunderbird}/** rw,
   # ...
}
```

Same could be useful for <abstractions/totem>, by upgrading this line [4]:

```
/{media,mnt,opt,srv}/** r,
```

Into variable-and-rule combo:

```
@{totem_extra_read_dirs} = /{media,mnt,opt,srv}/
#include <tunables/totem.d>

#...
@{totem_extra_read_dirs}/{,**} r,
#...
```

This would allow user to extend `@{totem_extra_read_dirs}` for his own use case, maybe ever overwrite (is this 
possible?) with `=` instead of `+=`, if he does not like access to default media/mnt/opt/srv paths.

Although it would not work with abstraction, so that rule should move into `usr.bin.totem` itself, just take this as 
more-or-less contrived example for now.

To wrap this up, I am suggesting to apply this guideline and refactor current profiles (and consider it while writing 
new ones), to use variables and some sort of tunables include, like directory:

```
#include <tunables/usr.bin.thunerbird.d>
```

Or single file:

```
#include <tunables/usr.bin.thunderbird>
```

Or any other suggestions you have.

Thanks for reading, an I am awaiting for your comments.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882218
[1] 
https://gitlab.com/apparmor/apparmor-profiles/blob/cc51ebcda9d874124358b01ca09b17414293b15d/ubuntu/18.04/usr.bin.thunderbird#L163
[2] https://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/apparmor/program.soffice.bin#n24
[3] https://gitlab.com/apparmor/apparmor/blob/master/parser/apparmor.d.pod#L1261
[4] https://gitlab.com/apparmor/apparmor-profiles/blob/master/ubuntu/18.04/abstractions/totem#L29