[apparmor] [RFC] Refactoring apparmor-profiles repository

[Vincas Dargis]

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 
<abstraction/foo>, 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?