The plans have been discussed several places. There isn't a canonical reference atm. But the basics are below
Basically apparmor is going to have to track pre and post pivot root. Policy will have some options open to it.
1. transition to policy designed for within pivot_root
2. keep current policy and define how post pivot_root policy is to be transformed.
3. combine 1 & 2 via stacking. So both solutions can be used similtaneously
Basically, when a new mount ns is created there is going to be a new shared var used for transforms. Policy will define how this is updated on pivot_root and also control which parts of the stack it applies to. It will be possible (though strongly NOT recommended) to keep the current behavior so that current policy does not break on kernel upgrade.
What apparmor need to do this is some new hooks around namespaces and pivot_root. Hopefully we can get these landed soon.
The plans have been discussed several places. There isn't a canonical reference atm. But the basics are below
Basically apparmor is going to have to track pre and post pivot root. Policy will have some options open to it.
1. transition to policy designed for within pivot_root
2. keep current policy and define how post pivot_root policy is to be transformed.
3. combine 1 & 2 via stacking. So both solutions can be used similtaneously
Basically, when a new mount ns is created there is going to be a new shared var used for transforms. Policy will define how this is updated on pivot_root and also control which parts of the stack it applies to. It will be possible (though strongly NOT recommended) to keep the current behavior so that current policy does not break on kernel upgrade.
What apparmor need to do this is some new hooks around namespaces and pivot_root. Hopefully we can get these landed soon.