[apparmor] RFC: Policy versioning

[Jamie Strandboge]

I'm going to reply to this one separately from the other parts of your
response.

On Mon, 2017-12-11 at 10:33 -0800, John Johansen wrote:
> On 12/11/2017 09:30 AM, Jamie Strandboge wrote:
> > On Sun, 2017-12-10 at 03:05 -0800, John Johansen wrote:
> > > 4. Limit distros ability to compile policy to the current kernels
> > >    feature abi
> > > 
> > >   Along with this Distros will no longer be able to set a default
> > >   policy compile that will use the current kernel's abi. This
> > > will
> > > not
> > >   even be supported at the distro level as the project can not
> > > afford
> > >   to break the feature abi of current policy for kernel
> > > developers.
> > > 
> > >   To address this a new tool will be added to extract the kernel
> > >   features abi, and tooling will be updated to allow users update
> > > a
> > >   profiles abi and thus begin development on newer versions.
> > > Basically
> > >   a per user opt in only approach.
> > 
> > I'm a little confused by this. Why would it be bad for a distro to
> > compile policy to a *versioned* policy cache for the current
> > feature
> > abi? I understand wanting to obsolete *un*versioned policy caches.
> > 
> 
> Because this is effectively equivalent to what got us in trouble
> and led to the revert. Whether we like it or not, the ability to
> to do this system wide, and at the distro level has to go away
> to safe guard our ability to work with upstream.
> 
> This is going to have to be a user only per profile opt-in. Yes it
> sucks from the distro/profile developer pov, but at this point we
> have to be extra paranoid about it.

Maybe I'm dense, but the proposal is pretty broad and seems to be
addressing several related issues and I'm finding it difficult to
connect the dots.

I suggest identifying use cases and then describing how the proposal is
meant to address these. I also suggest putting the proposal up
somewhere-- and then people can comment and the document can grow.
Perhaps there is something on gitlab to help with this? (otherwise just
the wiki would work).

I'm sure I've missed some use cases, but here are the ones I'm thinking
about. Specifics like "the parser should do this, the apparmor package
in the distro that, the policy in the distro should do something, the
kernel package something else, etc" would be appreciated.

= Supporting upstream kernel developers =
Consider the upstream (non-AppArmor) kernel developer running OpenSUSE
who runs an otherwise stable OpenSUSE system with AppArmor enabled but
compiles her kernels based on local branches to Linus' tree. How should
the system be configured so the the developer can pull in Linus' tree
which has new AppArmor features without breaking the system?

= Ubuntu user testing upstream or bisect kernels =
Consider the Ubuntu user with a kernel bug who has been asked to test
various upstream and/or bisected kernels on an otherwise stable Ubuntu
system (these kernels might be substantially older or newer than what
was shipped with the apparmor userspace). How does he run these kernels
without breaking his applications?

= Ubuntu HWE kernels =
Consider the Ubuntu user who tracks the hwe kernels but otherwise has
an stable Ubuntu system (eg, non-updated apparmor userspace). How does
she run these kernels without breaking her applications?

= Distro kernel developer using non-upstream AppArmor kernel features =
Consider the kernel developer that has non-upstream features (eg,
OpenSUSE that pulls back network compat or Solus that pulls from jj's
tree). How does the developer pull in new upstream kernels with new
AppArmor features into the distro so as not to break users of the
development release?

= Distro kernel developer using only upstream AppArmor =
Consider the kernel developer that uses only upstream AppArmor features
(eg, Debian). How does the developer pull in new upstream kernels with
new AppArmor features into the distro so as not to break users of the
development release?

...

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20171211/cd97946e/attachment.sig>