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


--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to