[apparmor] AppArmor 2.8.95 without out-of-tree kernel patches?

[John Johansen]

On 06/13/2014 09:54 PM, John Johansen wrote:
> Sorry these got lost in the mail black hole and I would have completely
> missed them if they hadn't been pointed out to me. I am missing the
> original message ids so, this is being done as a new message quoting
> the originals
> 
>>> Hi,
>>>
>>> it's being discussed [1] what version of the AppArmor userspace we'll
>>> ship in Debian Jessie.
>>>
>> That is, most likely: 3.16. In case it changes anything wrt.
>> the timing of pushing AppArmor patches to Linux mainline.
>>
> There might be a few but nothing significant
> 
>>> On the kernel side, most likely we'll have what is in the mainline
>>> version of Linux that is chosen for Jessie; possibly a few backports
>>> of things that land into mainline after this kernel is released might
>>> be added on top, but I don't think we'll have any out-of-tree patches.
>>>
> the situation here is better as the main interface patches have landed,
> now its just the extended mediation patches, most of which are dependent
> on the core rework.
> 
>>> On the userspace side, we currently have 2.8.0 (!), and hopefully
>>> we'll get 2.8.3 soonish. For Jessie, I think we basically have to
>>> choose between 2.8.3 and 2.8.95.
>>>
> 2.8.4 should be out in a few weeks
> 
> also I expect the next 2.9 beta, which will be 2.8.96 will also ship
> in a few weeks. The reason we do the betas as 2.8.XX where XX is a
> big number is incompatibilities between rpm and debian packaging
> around naming (2.9~Beta1, and different similar names caused problems
> with one or the other).
> 
>>> I've read on the relevant Ubuntu freeze-exception request [2] that
>>> AppArmor 2.8.95 was tested with Ubuntu kernels, with and without the
>>> ptrace and signal mediation ones.
>>>
> yes, part of the testing is against the vanilla upstream kernel.
> 
>>> That's good to know, but I'm wondering if anyone has tested AppArmor
>>> 2.8.95 without out-of-tree kernel patches at all, using this
>>> combination in production, and/or shipping it to users.
>>>
> I have run tests on it, and brought up systems with it. It should work
> but I can't say I know of anyone shipping 2.8.95 with a vanilla kernel.
> 
>>> Has anyone here any experience to share on this topic?
> 
> Basically we try to keep apparmor kernel and userspace somewhat independent.
> That is the kernel tries to maintain backwards compatibility with older
> userspaces, and newer userspaces try to remain compatible with older kernels.
> 
> Ubuntu does have some combinations that do test some of these configurations.
> Eg. the backport kernels take the newer kernels and put them on older
> userspaces.  So we have a trusty (3.13 kernel + out of tree patches) back
> on precise with is basically a 2.8 userspace.
> 
> At the moment Ubuntu doesn't support a newer userspace on older kernels but
> part of the validation process (for apparmor) is testing against vanilla
> upstream. 
> 
> The regression tests on the 2.8.95 userspace check the kernel for supported
> features and run different tests.
> 
just two more data points here.
1. while the upstream test kernels aren't a supported configuration in
Ubuntu, so people do use them, and it is what the kernel team recommend
people try first when hunting for bugs (any kernel bug not just apparmor).
So they do get some testing beyond me

2. The touch kernels have been running a backport of saucy apparmor*
(not upstream, but not trusty with signals and ptrace), and a 2.8.95
based userspace. This has been the tested config for a couple of months
and will change shortly but it should help show that the 2.8.95 does
userspace does support kernels without all the latest features.

* It has the mount rules, some network changes, the query interface for
  dbus, and some of the implicit label base. No signal, or ptrace rules,
  no autoselection of supported features sets for better backwards compat.