[apparmor] [RFC] Refactoring apparmor-profiles repository

[Vincas Dargis]

On 6/11/18 10:18 PM, Seth Arnold wrote:
> On Sat, Jun 09, 2018 at 03:38:48PM +0300, Vincas Dargis wrote:
>> profiles or should it backport it's rules inline? If it would be known that
>> Ubuntu 18.10 will not have AppArmor 4.13, what if someone from OpenSUSE
>> Tumbleweed would like to introduce new profile with 4.13 features? It can't
>> go into ubuntu/18.10...
> 
> I think the intention was profiles for other distributions might get their
> own top-level directory.. e.g. opensuse/ and so on.

Oh I see. Though I would say that this technique would only bring too 
much duplication.

> So while the Ubuntu ones are split apart by version, rolling-release
> distros might just edit their profiles in place.

Modifying in place means again, IMHO, duplication, non-sharing of work.

I believe that custom distribution-depended modifications could be 
really handled with variables and conditional includes.

> Does this change your thinking?

No. Having directory tree for each interested-enough distro looks like 
too much of noise and confusion.

If some new distro decides to start AppArmor'ing, should it copy from 
`ubuntu`, `openSUSE` or `arch` directory if it's not based on any of these?

Not-having `openSUSE` directory for so much time probably also says 
something...

Let's see contrived example #1 on how single cross-distro-shared profile 
repository could work, by using tunable variables:

Imagine we have `/usr/bin/foo` application, that also occasionally uses 
`/usr/lib/foo/foo_helper.sh` helper-executable. We have a problem that 
these lib-paths are different on Debian and openSUSE.

So let's say we would have a rule/guideline that application profile 
should have this include, in addition to `tunables/global` :

```
# as before:
#include <tunables/global>

# not a conditional include!
#include <tunables/usr.bin.foo>

# ...rest of profile...
```

Where `tunables/usr.bin.foo` looks like this:

```
# "upstream" defaults:

# can be made to confine /usr/local instances, if needed
@{foo_prefix} = /usr

@{foo_executable} = @{foo_prefix}/bin/foo
@{foo_lib_prefix} = @{foo_prefix}/lib/foo
@{foo_helper_executable} = @{foo_lib_prefix}/foo_helper.sh

# for distribution and third-party variable modifications:
#include if exists <tunables/usr.bin.foo.d/>

# for local system administrator modifications:
#include if exists <local/tunables/usr.bin.foo>
```

Now, `tunables/usr.bin.foo.d/debian`, on Debian-bases system, could look 
like this:

```
@{foo_lib_prefix} += @{foo_prefix}/@{multiarch}/foo
```

Meanwhile on openSUSE, `tunables/usr.bin.foo.d/openSUSE` could look like 
this instead:

```
@{foo_lib_prefix} += @{foo_prefix}/lib{,64}/foo
```

And now in the main `/etc/apparmor/usr.bin.foo` profile:

```
# ...

profile foo @{foo_executable} {

   #Main executable
   @{foo_executable} mr,

   # Other executables
   @{foo_helper_executable} Cx -> foo_helper,

   # ...
}
```

And that should work, or be made to work by modifying tunables, on 
various distros.

Let's see another kinda-semi-contrived-based-on-real-story example #2:

Let's say openSUSE Tumbleweed people discovered that Thunderbird 60 now 
needs to enumerate graphics devices, and that can be fixed with 
including `<abstrations/dri-enumerate>` abstraction, that is available 
in latest AppArmor 2.13, the version openSUSE Tumbleweed are actually 
shipping.

So, they send pull request to `apparmor-profiles` repository to add 
`#include <abstractions/dri-enumerate>` into 
`apparmor/2.13/usr.bin.thunderbird` profile. Note the 2.13.

Meanwhile, Debian Sid users with Experiment repository has also 
discovered that their Thunderbird 60 does not work  (true story, [0]). 
Sadly, `dri-enumerate` abstraction is not yet available in Debian Sid, 
as it ships AppArmor 2.12. Well, not so big deal, just update 
`apparmor/2.12/usr.bin.thunderbird` profile  (.12, not .13!) by 
back-porting `dri-enumerate` contents from latest AppArmor 2.13.

And (imagine) that 2.12 profile version will ship in Ubuntu 18.10 too, 
and any other Debian-based or even any AppArmor 2.12-based distro 
actually. All using same profile.

When Debian family finally updates to AppArmor 2.13, they now can use 
latest `apparmor/2.13/usr.bin.thunderbird` profile, already fixed 
without backports by bleedingedgers! Yay :)

End of example #2.

Also, we already have distro-specific fixes in abstractions and they are 
not split by distrbution-specific directories...

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900840#17