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
