[apparmor] apparmor policy versioning

[John Johansen]

On 07/10/2013 02:51 PM, Seth Arnold wrote:
> On Wed, Jul 10, 2013 at 02:18:22PM -0700, 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
> 
> I'm pretty sure I've seen a matrix somewhere that described the different
> mediation semantics and the different things our kernel patches provide
> mediation points for somewhere in a previous discussion of policy
> versioning.
> 
> But my archives are pretty limited -- does anyone else recall this
> discussion and have a pointer to the big ugly matrix that I hope I
> didn't imagine?

the matrix does exist but it didn't really cover everything it should
have. I need to try reworking it and provide a larger matrix for
consideration

> 
> I think we need a concrete list of problems being solved by policy
> versioning and problems _not_ being solved by policy versioning.
> 

It a nut shell its different semantics, and potentially behaviors
(as policy does encode some behavior)

> Mixed versions of 'main policy' and abstractions scares me.
> 
> I'm disinclined to support the /etc/apparmor3.d/ because it feels far
> too course -- would capability block_suspend, wake_alarm, syslog be
> features exposed in apparmor3.d? What would we do when a new capability
> (e.g. CAP_MODIFY_CPU_MICROCODE) is added?
> 
> One final thought to throw out is that SELinux versioned their policy and
> decided to make it feasible to load only a range of supported policies --
> say, the previous three policy versions. This seems like a nice way to
> allow eventually removing features should we desire, but I fear a strict
> policy of "we support previous 3" might not give us the flexibility we'd
> like. (At least, I don't see us often removing features.)
> 
we would not do, we only support 3 previous releases, we would look at
deprecating and removing on a case by case basis.  It could be 3 or 5 or
10 only time will tell.