Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
On 6/18/18 2:28 AM, John Johansen wrote:
On 06/17/2018 05:56 AM, Vincas Dargis wrote:
With policy versioning we could have single profile for all future AppArmor releases? Basically, no
more need to have these directories (nor "ubuntu", neither "apparmor/x.y")?
A possibility, that I would certainly like to get to, but I don't think we will
be able to get to it with the 3.0 release
Oh, we need some more "conditioning" features I guess?
Basically the big issue is installing policy with rules that supports new
features on older systems that don't have support for the feature. You could
update the userspace but most stable releases are unwilling to do this. To help
deal with this in the past we have been front running the features in the
parser before they land upstream, but we really need to get away from doing
that. We could wrap rules in conditional statements but with the current
implementation the parser will break as conditionals are not a preprocess and
the rules in their blocks must be parsable.
The long term goal is to allow defining parsing patterns within the parser
language itself. So we could add a pattern that would be used to skip/downgrade
a rule if the parser doesn't support the feature. So something along the lines
of
if !parser_supports(Xapparmor) {
ignore pattern 'X' # some expression that will let the parser get
past the unsupported rule
}
and eventually if the rules follow supported patterns and don't need anything
specially allow declaring the rule patterns in policy entirely.
This "x_supports" is planned for > 3.0?
Will we have new policy version numbers on every minor AppArmor release (with
new/updated abstractions)?
Using policy versioning as a name is really as misnomer, at least at the policy
level, the idea certainly started out as such but it has evolved from there.
The idea is that we declare the supported feature abi that the policy was
developed under right in the policy it self. This will give a similar effect as
using feature pinning but on a per profile basis instead of applying to all
policy on the system. If the feature abi is not declared in policy then, policy
will fall back to feature pinning and then if there is no declaration the
compile will fallback to the 4.14 feature abi as the default.
Policy wise the base of policy versioning is the new feature rule.
features=,
Also instead of sticking the features into a feature file they can be included
inline
features={ blah, blah blah }
the features file will be the same as what is currently used for caching and
feature pinning. And in support of this, there will be a couple of additions to
the parser language to help identify what is currently supported.
kernel_supports
parser_supports
policy_supports
supports - asking about what is supported for this compile which is an
intersection of what the kernel and the policy supports
hopefully if we do it right we can hide most conditionals within the
abstractions.
to abstract some of the details away we are going to wrap the features= rule in
an include which will allow us to abstract away anything new we come up with
the include could contain multiple features= rules, defining some variables
that can be used conditionally etc.
It is the include file naming and how packaging of policy is handled that would
be the closest to what policy versioning implies, and I have been struggling
with how best to do this
OK so it's "versioning" against features. That's useful, as two
distributions might look like having the "same" AppArmor v3.0, though
one distro might not have DBus mediation in Kernel yet, for example.
Could you give us an example of how versioned profile snippet will look like? Meaning, "if
apparmor/policy version is >= X, then include , else copy-pasted
rule...".
So I'd like to address the version number first. I would like, if possible, to avoid having
to do "if version >= X", I am not saying there won't be cases where something
of the sort is needed but I would rather the conditionals be along the lines of
if (supports(X)) {
include
}
So for every new abstraction there should be defined as "a feature" in a
version/3.0 include, basically? This "supports" will look at included
feature set and/or distro feature file, right?
In recent Thunderbird profile backport [0] I've copied
abstractions/dri-enumerate content inline, as Debian Sid does not yet
have 2.13. What if abstractions/dri-enumerate would have been available,
but not up-to-date, with some rules missing?
We aren't going to add a feature definition for every abstraction
change..? (you do mention abstraction versions later, but see below)
and that we keep the conditionals in the abstractions as much as possible
The version abstraction at its most basic would look like
$ cat version/3.0
# feature set supported by the 3.0 release
features=
# allow policy to also support kernels with the
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
On 06/17/2018 05:56 AM, Vincas Dargis wrote:
> On 6/15/18 8:05 PM, John Johansen wrote:
>> On 06/15/2018 09:36 AM, Vincas Dargis wrote:
>>> On 6/14/18 10:22 PM, Jamie Strandboge wrote:
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.
>>>
>>> Yes there will be duplication for the packages that ships updates in stable
>>> versions (like Thunderbird and Firefox), while AppArmor abstractions are
>>> not being upgraded. That's the main point of basing on AppArmor versions -
>>> for clearly defining available abstractions (and their update) and for
>>> policy features/versions, that profiles depend heavily on.
>>>
>>
>> So I agree that the repo should be refactored but I am not sure this
>> is the approach that should be taken (possibly for older policy) I
>> need to think about it more. With all policy becoming versioned we are
>> going to see a mixing of different version on the same system. We
>> certainly could segregate on version, making it easier to see what
>> hasn't been updated but then profiles that haven't been updated might
>> get left out and that isn't what we want either.
>
> With policy versioning we could have single profile for all future AppArmor
> releases? Basically, no more need to have these directories (nor "ubuntu",
> neither "apparmor/x.y")?
>
A possibility, that I would certainly like to get to, but I don't think we will
be able to get to it with the 3.0 release
Basically the big issue is installing policy with rules that supports new
features on older systems that don't have support for the feature. You could
update the userspace but most stable releases are unwilling to do this. To help
deal with this in the past we have been front running the features in the
parser before they land upstream, but we really need to get away from doing
that. We could wrap rules in conditional statements but with the current
implementation the parser will break as conditionals are not a preprocess and
the rules in their blocks must be parsable.
The long term goal is to allow defining parsing patterns within the parser
language itself. So we could add a pattern that would be used to skip/downgrade
a rule if the parser doesn't support the feature. So something along the lines
of
if !parser_supports(Xapparmor) {
ignore pattern 'X' # some expression that will let the parser get
past the unsupported rule
}
and eventually if the rules follow supported patterns and don't need anything
specially allow declaring the rule patterns in policy entirely.
> Will we have new policy version numbers on every minor AppArmor release (with
> new/updated abstractions)?
>
Using policy versioning as a name is really as misnomer, at least at the policy
level, the idea certainly started out as such but it has evolved from there.
The idea is that we declare the supported feature abi that the policy was
developed under right in the policy it self. This will give a similar effect as
using feature pinning but on a per profile basis instead of applying to all
policy on the system. If the feature abi is not declared in policy then, policy
will fall back to feature pinning and then if there is no declaration the
compile will fallback to the 4.14 feature abi as the default.
Policy wise the base of policy versioning is the new feature rule.
features=,
Also instead of sticking the features into a feature file they can be included
inline
features={ blah, blah blah }
the features file will be the same as what is currently used for caching and
feature pinning. And in support of this, there will be a couple of additions to
the parser language to help identify what is currently supported.
kernel_supports
parser_supports
policy_supports
supports - asking about what is supported for this compile which is an
intersection of what the kernel and the policy supports
hopefully if we do it right we can hide most conditionals within the
abstractions.
to abstract some of the details away we are going to wrap the features= rule in
an include which will allow us to abstract away anything new we come up with
the include could contain multiple features= rules, defining some variables
that can be used conditionally etc.
It is the include file naming and how packaging of policy is handled that would
be the closest to what policy versioning implies, and I have been struggling
with how best to do this
> Could you give us an example of how versioned profile snippet will look like?
> Meaning, "if apparmor/policy version is >= X, then include ,
> else copy-pasted rule...".
>
So I'd like to address the version number first. I would like, if possible, to
avoid having to do "if version >= X", I am not saying there won't be cases
where something of the sort is needed but I would rather the conditionals be
along the lines of
if (supports(X)) {
include
}
and th
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
On 6/15/18 8:05 PM, John Johansen wrote: On 06/15/2018 09:36 AM, Vincas Dargis wrote: On 6/14/18 10:22 PM, Jamie Strandboge wrote: 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. Yes there will be duplication for the packages that ships updates in stable versions (like Thunderbird and Firefox), while AppArmor abstractions are not being upgraded. That's the main point of basing on AppArmor versions - for clearly defining available abstractions (and their update) and for policy features/versions, that profiles depend heavily on. So I agree that the repo should be refactored but I am not sure this is the approach that should be taken (possibly for older policy) I need to think about it more. With all policy becoming versioned we are going to see a mixing of different version on the same system. We certainly could segregate on version, making it easier to see what hasn't been updated but then profiles that haven't been updated might get left out and that isn't what we want either. With policy versioning we could have single profile for all future AppArmor releases? Basically, no more need to have these directories (nor "ubuntu", neither "apparmor/x.y")? Will we have new policy version numbers on every minor AppArmor release (with new/updated abstractions)? Could you give us an example of how versioned profile snippet will look like? Meaning, "if apparmor/policy version is >= X, then include , else copy-pasted rule...". Maybe we could still use "apparmor/3.0" directory for new-style versioned profiles, leaving ubuntu/x.y for backpacking as it is now (We will have Ubuntu 18.04 for quite some time). If any day policy changes too much, "apparmor/4.0" could be added, or maybe we are sure enough that that's never going to happen, and we don't need that "3.0" at all? -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
On 06/15/2018 09:36 AM, Vincas Dargis wrote: > On 6/14/18 10:22 PM, Jamie Strandboge wrote: >> 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. > > Yes there will be duplication for the packages that ships updates in stable > versions (like Thunderbird and Firefox), while AppArmor abstractions are not > being upgraded. That's the main point of basing on AppArmor versions - for > clearly defining available abstractions (and their update) and for policy > features/versions, that profiles depend heavily on. > So I agree that the repo should be refactored but I am not sure this is the approach that should be taken (possibly for older policy) I need to think about it more. With all policy becoming versioned we are going to see a mixing of different version on the same system. We certainly could segregate on version, making it easier to see what hasn't been updated but then profiles that haven't been updated might get left out and that isn't what we want either. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
On 6/14/18 10:22 PM, Jamie Strandboge wrote: 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. Yes there will be duplication for the packages that ships updates in stable versions (like Thunderbird and Firefox), while AppArmor abstractions are not being upgraded. That's the main point of basing on AppArmor versions - for clearly defining available abstractions (and their update) and for policy features/versions, that profiles depend heavily on. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
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
>
> # not a conditional include!
> #include
>
> # ...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
>
> # for local system administrator modifications:
> #include if exists
> ```
>
> 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 `` 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 ` 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 updat
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
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
# not a conditional include!
#include
# ...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
# for local system administrator modifications:
#include if exists
```
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 `` 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 ` 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
Re: [apparmor] [RFC] Refactoring apparmor-profiles repository
[Sorry Vincas, I accidentally sent my first message directly to you rather than the list.] 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. So while the Ubuntu ones are split apart by version, rolling-release distros might just edit their profiles in place. Does this change your thinking? Thanks signature.asc Description: PGP signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] [RFC] Refactoring apparmor-profiles repository
Hi, I would like to suggest to change how apparmor-profiles [0] repository structure looks, how versioning works. Currently, we have ubuntu/18.10 directory [1] for the latest profile versions, but this naming/versioning scheme is not informative/transparent or useful enough. Ubuntu 18.10 is under development, and it is not clear if it will have AppArmor 4.13 or not? Meaning, should developer use new dri-enumerate abstraction (available in AppArmor 4.13 [2]) for improving ubuntu/18.10/* 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... To make this better, apparmor-profiles repository could be refactored by creating new directory tree, copying current ubuntu/x.y into apaprmor/a.b, where A is major, B is minor AppArmor version number. So, ubuntu/18.10 would be copied (moved?) into apparmor/4.13 ubuntu/18.04 -> apparmor/4.12 ubuntu/17.10 -> apparmor/4.11 ubuntu/17.04 -> ignore or apparmor/4.10? * ubuntu/16.04 -> apparmor/4.10 or ignore if 17.04 dir is used instead. * ubuntu/15.10 -> apparmor/4.9 (for Debian Jessie LTS) * - if Ubuntu 17.04 used AppArmor 4.10 too as in Xenial (16.04), it could be considered as more recent directory to be used (ubuntu/16.04 ignored). I don't know which version it was, there's no entry for that release in http://packages.ubuntu.com. I doubt this refactoring should "care" below ubuntu/15.10->4.9. AppArmor 4.9 is used in Debian Jessie which is LTS right now, so it would be actually useful to have 15.10->4.9 transformation, especially as this distribution might still receive Thunderbird update, for example. If any other distribution might need older directories, that's no problem to create more. Once this is in effect, downstream package maintainers could use profiles from the directory that reflects AppArmor used. This would allow to manage new feature inclusion in profiles in more straightforward way. I could, for example, start working on making Thunderbird profile more customizable with `#include if exists` in apparmor/4.13 directory, while backporting any other relevant fixes to 4.12 down to 4.9 (4.9 cannot use variable in profile name, so backporting is needed, see [3] as example). This can be done today too of course, but current Ubuntu-based versions just uses additional Brain-cycles, opaques view, and so demotivates. If it's ACK for the idea, there's one more question about implementing it, i.e. should it be copy or rename? I would got for copy, leaving all that exists as flat archive. [0] https://gitlab.com/apparmor/apparmor-profiles [1] https://gitlab.com/apparmor/apparmor-profiles/tree/master/ubuntu/18.10 [2] https://gitlab.com/apparmor/apparmor/blob/apparmor-2.13/profiles/apparmor.d/abstractions/dri-enumerate [3] https://salsa.debian.org/mozilla-team/thunderbird/merge_requests/1/diffs -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
