Hello,
Am Mittwoch, 10. Juli 2013 schrieb Jamie Strandboge:
> On 07/10/2013 04:18 PM, John Johansen wrote:
> > So it turns out we are going to need to support policy versioning
> > (Christian can gloat now).
I already wanted it when we enforced the trailing / on directory names
some years ago ;-)
> > We are looking at 2 different options
> >
> > 1. we support a version tag in files, with the tag required to be on
> > each>
> > file including any include.
> > When the parser detects mixed versioning does it
> > - gracefully convert between v2 and v3 policy
> > - just fail
> >
> > 2. we move to a new versioned directory /etc/apparmor3.d/ or
> > something of>
> > the sort with everything in /etc/apparmor.d/ remaining in v2
> > policy
> > (format and semantics)
> >
> > In this case what if a profile exists in both directories
> > - fail
> > - default to v3 on new kernels
> > - default to v2 on older kernels?
>
> I was initially thinking that for '1' if any profile or include had a
> v3 annotation, then it would be v3. But I don't think that works well
> and '1' doesn't cleanly separate. Ie, what happens if I update the
> base abstraction with a v3 rule? We decided today that the parser
> should probably support converting v2 policy to v3 by adding
> equivalent open rules on kernels that supported them (ie, v3 policy
> that acts like v2. Eg v2 policy doesn't have a dbus rule, so if the
> parser detected v2 policy it would add an implicit 'dbus,' rule). In
We'll probably also need support to upgrade to a newer profile version
in logprof or a separate 2to3 [1] tool (with a "just do it" option, and
a more selective one that asks about any difference).
Thinking about it, we could handle the versioning with something like
include <abstractions/compat_aa2> # v2 profile
or
include <abstractions/compat_aa3> # v3 profile
compat_aa2 would contain
dbus,
#include <abstractions/compat_aa3>
compat_aa3 would be empty for now, but can be filled when we switch to
aa4 one day.
The parser should check if the profile contains a compat_* abstraction.
If not, it should assume it's a v2 profile and include compat_aa2
silently (well, a warning would be nice).
The advantage of this solution would be that we don't need big changes
or feature list in the tools - it would just be another abstraction.
The only disadvantage of this method is that it will fail if we change
syntax or remove a rule. However, I don't expect this to happen ;-)
(for completeness: history tells us about the trailing / for directories
and removal of "set capability" - but that were very rare cases.)
> this manner, we could maybe only make the profiles themselves require
> the v3 tag since the parser would convert everything to v3 before
> policy load anyway (on kernels that supported it).
Having the version tag only in the main profile sounds like a good way,
and then assume the abstraction uses the same version. (To answer the
obvious question: if a v2 profile includes a v3 abstraction with a dbus
rule, just "don't care" while parsing - it's superfluous because v2
implies 'dbus' anyway.)
Besides that, at least the abstractions we ship will have the "correct"
version - and I'd guess not many people have their own abstractions.
> But again, what
> happens if I update the base abstraction to have a v3 rule and then I
> run a v2 kernel?
The parser would for example skip the dbus rules (which doesn't change
anything because dbus was not restricted in v2).
> I think there are a lot of corner cases that makes
> versioning in files difficult.
Indeed ;-)
> I prefer '2' because it allows us to cleanly separate. abstractions
> probably need to be copied wholesale into the v3 directory and
> maintained as v2 and v3 thereafter (though it does allow us the
> opportunity to clean out ancient v2 rules, but ugh, I don't think I
> want to have to be the one to test all those).
Exactly - cleaning out ancient rules is both boring and dangerous
because we _will_ get regression bugreports from at least one user ;-)
My general rule of thumb is: do not remove any permissions once they are
in a shipped profile or abstraction, unless it is a security problem or
a very obvious bug (and I don't expect bad side effects of the fix).
If an ancient rule doesn't hurt, well, then it doesn't hurt ;-)
> v2 policies can stay
> as v2 until we test them under v3 and then have them in both. I think
> we need to do it this way since people might reboot into different
> kernels and while policy should load and I don't think we guarantee
> that v3 policy compiled with a v3 parser loaded into a v2 kernel will
> work as expected (ie, just like v2 policy, v2 policy and a v2
> kernel). As such, when both exist, use the one that is appropriate
> for the kernel.
Exactly this is the reason why I don't like to have a separate directory
with a duplicated set of the profiles. I have more than enough
experience with code duplication[2], and learned to avoid the "cp"
command at any price.
With an additional copy of the profiles, we'll end up in a maintenance
hell - and users will kill us because they have to update two profiles
instead of one if they want to switch kernels.
Regards,
Christian Boltz
[1] does this name remind you to something? ;-)
[2] to be exact, cleanup of code duplication in PostfixAdmin
--
Comic Sans
Man möge mir verzeihen, aber ich möchte mich im Rahmen dieses Essays in
erster Linie mit Schriften auseinandersetzen, nicht mit Krankheiten.
[http://praegnanz.de/essays/136/typo-im-web-html-schriften-unter-der-lupe]
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
