[apparmor] RFC: Policy versioning

Tue Dec 12 12:59:36 UTC 2017

On Mon, 2017-12-11 at 14:56 -0800, John Johansen wrote:
> On 12/11/2017 01:26 PM, Jamie Strandboge wrote:
> > 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.
> > 
> 
> Yes it is pretty broad, with that said most of the components are
> needed for policy versioning or dealing with the current upstream
> feature issue which was the final impetuous to move to policy
> versioning.
> 
I may not have been clear-- I wasn't saying that the proposal was too
broad or too anything (I said 'related' because I understand all of it
is needed); I was saying that I personally couldn't get from A to B
from a distro perspective.

> > I suggest identifying use cases and then describing how the
> > proposal is
> > meant to address these. I also suggest putting the proposal up
> 
> Hrmmm, I thought I was pretty explicit and up front about what this
> was meant to address. I covered 7 problems that we currently have and
> then did provide a few examples through out where I thought it was
> necessary.

You were explicit, but as sent up, *I* didn't quite see 'do this to fix
that'.

> > 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 don't see how gitlab is going to help, we need an open discussion
> and we need it yesterday (well 6 months ago but ..). We can certainly
> put the doc on git lab or the wiki but moving the editing to there
> effectively hides the discussion more than having it on an open
> mailing list.

My suggestion wasn't to replace mailing list discussion, but to capture
outcomes. This proposal is *large* and I only suggest the specification
be captured somewhere else to help others just coming to it and later,
implementors since I suspect this thread to be long and details to be
missed otherwise.

> 
> > = 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?
> > 
> 
> Ideally they just pull in Linus's tree. That is the whole point of
> this. There policy won't use the new features in Linus's tree unless
> they opt-in, and manually update policy to the new abi.
> 
Well, of course. Your initial email has 7 related problems with 7
solutions with options, but what I was after is what *specifically* do
you see each part (kernel, parser, upstream policy, initscript, distro,
distro policy,  config, user, etc) doing to achieve this? This is the
bit I was having trouble with-- the actionable items for consumers of
apparmor where everything works together to achieve "the user can just
boot into any kernel and it pretty much just works". Again, sorry if
I'm being dense or wasn't clear in what I needed to effectively respond
to the proposal.

Most of your responses to the below were 'it just...' but what specific
actions need to happen for the use case for 'it just...' to work? Put
another way-- if we implemented your proposal, how do you see OpenSUSE
(or Ubuntu or Debian or ...) using the tools in your proposal to get
from where they are now to where things just work?

Eg: "apparmor parser and kernel cap at 4.14 when feature file not used;
upstream policy starts using a feature file for all its policy
(solution '1'); if OpenSUSE does nothing else then new kernels and new
upstream policy that is pulled into distro policy is capped at 4.14.
The distro policy can leverage post 4.14 features by doing <something>
to abstractions and <something else> to account for unknown rules.
Etc...

In light of that, I've left the use cases intact below.

...
> 
> > = 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/20171212/94537b5c/attachment.sig>