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=<features/file>,
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 <abstraction/foo>,
> 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 <abstraction/foo>
}
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=<features/4.17>
# allow policy to also support kernels with the older out of tree patches
features=<features/out_of_tree_net_and_af_unix>
@{version}=3.0 # or perhaps define the var as @{abi} instead doesn't matter
as long as we are consistent
$
The idea behind the @{version} variable is then that could be used in policy to
do things like
include <abstractions/@{version}/...>
for version specific bits if needed.
a profile file would then do
include <version/3.0>
to set what its policy version
packaging and dealing with missing bits of policy is where I am failing atm,
and 3.0 won't have debhelpers or rpm macros to help with packaging needs around
policy versioning.
I am not sure if we want to split the version and feature files into their own
packages that packaging can setup dependencies on or whether it should just be
dealt with in policy.
policy authors could do things like
include if exists <version/3.0>
if they want the ability to fallback to a different version, but use a regular
include if they want the missing dependency to fail.
I suspect we are going to end up with a mix of packaging and policy magic
depending on the policy author needs. Policy that the apparmor project ships
could be easily setup to have packaging dependencies but LXD might choose to do
something more flexible as they are dynamically generating policy
> 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?
>
That is a possibility, and whether or not we are sure that policy will never
change enough to require a new version number we are going to keep the option
to provide one because if we don't, we will need it later.
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
