[apparmor] RFC: Policy versioning

[John Johansen]

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.

It evolved to be something more than just policy versioning to be a
single plan to address all the main policy problems. Parts of the
design evolved/changed as new pieces of the puzzle were brought into
play.

If we just wanted to address the current crisis around kernel
features. We would cap policy at the 4.14 abi and never add a new
feature, but for some reason I don't think that would make people
happy.

Or at the other end if we just wanted to deal with the problem of
policy being written for different versions (again another way we can
look at the kernel feature issue that got us a revert in 4.14), we
could just go to monolithic policy, and only load it it exactly
matched the kernel features set. No packaging of policy with
applications, only one policy on a system at a time. But again I don't
think people would be happy with that

Policy versioning, policy hashing, conditional includes, new
variables, better conditionals, and removing the distros ability to
set the policy abi to the current kernel abi all work in concert to
solve the current kernel problem without resorting to one of the two
above extreme solutions.

At the same time that also provide us the opportunity to address some
of the other issues we have had with policy.


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

The large one is of course address the current problem of upstreaming
features without breaking current policy, which includes distributed
packaging of policy.

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


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

certainly guide lines that can be worked on.

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

But as outlined in the document, the only guaranteed way to avoid
breakage for kernel developers is freeze the abi and NEVER add a new
feature.

Well there is another and that is called remove apparmor and disable
it permanently but I am pretty sure that also runs afoul of changing
the userspace abi.

> = 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?
> 

He just does it. The kernel to the extent possible will support older
policy abis. The userspace to the extent possible will support down
grading policy to older kernels, when needed.

Now we do have an issue with not having any policy to load potentially
breaking the system. As certain applications seeing apparmor enabled
will expect policy, but no policy is available. In this case we are
going to need a switch or something to basically turn apparmor off.
That is to say if early policy load doesn't happen either apparmor is
disabled (default) or the system refuses to boot.

Because late policy load based off of a compile (even with the policy
being versioned) won't cut it for certain confined system daemons.

> = 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?
> 

Just runs them, the existing policy will still be used, it just won't
leverage new features.

> = 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?
> 

Uh their policy versioned to state it supports those features or not,
again. They just use their existing policy. If it supports the new
features already we pray the person who set its versioning did a good
job because it has just become active. However as an upstream we at
least now have the defence that they are using an out of
tree/non-upstream patch at some level. If it doesn't there policy just
continues being enforced as it used to.

> = 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?
> 
> ...

They just bring in the kernel. Policy continues to use the abi it was
developed for. And when they are ready for a policy update they just
pull it in regardless of whether it matches the kernel.

The only thing they need to worry about is whether the userspace
handles the features in policy, which is the same problem they have
with pulling in policy today.