Top posting since this email is quite long. Yes, Seth is right, the idea was that distros would have their own top-level directory and iterate as desired.
Without going into the whole story, OpenSUSE didn't use the apparmor-
profiles repo because they preferred to work with profiles/apparmor.d
in the apparmor upstream repo. Ubuntu preferred to let some in-progress
profiles live in the apparmor-profiles repo. Debian decided to pull
from everywhere and use its apparmor-profiles-extra deb for shipping
in-progress files.
These days most of the activity with the apparmor-profiles repo is not
so much from the distro but instead the wider community (of which the
distros are part of). Since the toplevel distro dir approach in
apparmor-profiles repo has cleared failed to catch on, I think it makes
a lot of sense to refactor this. Your idea about apparmor/2.13,
apparmor/2.12 is interesting. I suspect there will be some duplication
there too, but I'm not terribly about it.
On Tue, 2018-06-12 at 20:40 +0300, Vincas Dargis wrote:
> 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
--
Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
