[apparmor] apparmor policy versioning

[Seth Arnold]

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?

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

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

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130710/8fb9d8ea/attachment.pgp>