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
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor