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
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
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
