[apparmor] apparmor policy versioning

Jamie Strandboge jamie at canonical.com
Wed Jul 10 22:13:22 UTC 2013


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). The question because how we support it
> 
> 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 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). But again, what happens if I update the base
abstraction to have a v3 rule and then I run a v2 kernel? I think there are a
lot of corner cases that makes versioning in files difficult.

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

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130710/0bc0e7a1/attachment-0001.pgp>


More information about the AppArmor mailing list