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

John Johansen john.johansen at canonical.com
Mon Dec 4 18:04:37 UTC 2017


On 12/03/2017 02:24 AM, Vincas Dargis wrote:
> 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.
> 
yes variables currently can only be defined in the preamble, before the profile definition.
It is important to note that the order of the vriable definition does NOT matter. It could be defined before the include <tunables/global> and reference variables in there and still be fine, so there is some flexibility in how/where to define it

The easiest way to deal with profile specific variables is stick them directly in the
preamble. It keeps everything together and is much easier for a user.

However as you note this does run into the broken package manager problem. Yes I really do think how package managers deal with this type of stuff is broken, but we are currently stuck with that behavior


> 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.
> 
sorry no overwriting is currently not supported

> 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:
> 

yeah making better use of variables in the profiles has been long desired as it real does greatly improve tuning of profiles

> ```
> #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
> 




More information about the AppArmor mailing list