Re: regression in 4.14-rc2 caused by apparmor: add base infastructure for socket mediation

[John Johansen]

On 10/24/2017 04:03 AM, James Bottomley wrote:
> On Tue, 2017-10-24 at 08:39 +0200, Thorsten Leemhuis wrote:
>> Lo, your friendly regression tracker here!
>>
>> On 03.10.2017 09:17, John Johansen wrote:
>>>
>>> On 10/02/2017 11:48 PM, Vlastimil Babka wrote:
>>>>
>>>> On 10/03/2017 07:15 AM, James Bottomley wrote:
>>>>>
>>>>> On Mon, 2017-10-02 at 21:11 -0700, John Johansen wrote:
>>>>>>
>>>>>> On 10/02/2017 09:02 PM, James Bottomley wrote:
>>>>>>>
>>>>>>>
>>>>>>> The specific problem is that dnsmasq refuses to start on
>>>>>>> openSUSE Leap 42.2.  The specific cause is that and attempt
>>>>>>> to open a PF_LOCAL socket gets EACCES.  This means that
>>>>>>> networking doesn't function on a system with a 4.14-rc2
>>>>>>> system. Reverting commit
>>>>>>> 651e28c5537abb39076d3949fb7618536f1d242e
>>>>>>> (apparmor: add base infastructure for socket mediation)
>>>>>>> causes the system to function again.
>>>>>> This is not a kernel regression,
>>>>> Regression means something that worked in a previous version of
>>>>> the kernel which is broken now. This problem falls within that
>>>>> definition.
>>>> Hm, but if this was because opensuse kernel and apparmor rules
>>>> relied on an out-of-tree patch, then it's not an upstream
>>>> regression?
>>> While its true that previous opensuse kernels were relying on an
>>> out of tree patch for doing mediation in this area, the real issue
>>> is the configuration of the userspace on the system is setup to
>>> enforce new policy features advertised by the kernel. Regardless of
>>> whether policy has been updated to deal with it.
>>
>> Did anything came out of this discussion?
> 
> Not really, no.  I've got the patch reverted locally, so it's not
> causing *me* problems anymore.
> 

actually a lot of work and testing has been done. A regression was
found, the fix is in testing and it should land soon, but its not the
regression you are having issues with.

>>  I checked LKML and recent commits, but missed if anything happened.
>> But it seems this problem annoys quite a few of people on various
>> distros. It turned out one of the the regressions in my last
>> regression report seemed to be due to the changes in apparmor. See:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=197137#7
>>
>> That commit links to two bugs filed for Debian and Ubuntu:
>> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1724450
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877581
>>
>> The stuff even made the news:
>> https://www.phoronix.com/scan.php?page=news_item&px=AppArmor-Linux-4.
>> 14
>>
>> It's obviously Linus to decide in the end, but from my understanding
>> of the whole "no regressions" rule this looks quite a lot like a
>> regression to me.
> 
> It's certainly a lack of co-ordination between all the apparmour using
> upstreams, yes.  I think of it as a regression because I have no way
> other than reverting the patch of getting my system running again.
> 

its not a lack of coordination, regardless of coordination this would
have happened for people front running the suse distro kernel due to
how the apparmor userspace is configured. Could it have been handled
better for kernel devs? Certainly, but the issue you are encountering
is a userspace configuration issue.

Distros get to choose how apparmor is configured, and what certain
defaults are. The suse default configuration is to not pin the
features abi (there are pros and cons depending on what you want),
which essentially means if you are front running the distro kernel and
policy with an upstream kernel you are a policy dev, and you are going
to be hit with stuff like this.

You have a couple userspace options available to you and a couple
kernel options without having to revert the patch.

- You can update your policy.

- You can pin the feature set abi to that of the distro kernel, and
  what your policy was developed for.

- You can disable apparmor in grub

- You can disable apparmor in the kernel config

I have been discussing pinning the feature abi with distros
maintainers (the ability has been around for years) and the Debian
maintainer has been planning, for a while now, to use it by default
for stable releases.  However a similar decision has not been made for
other distros yet.

Long term we are working on a more flexible solution, that won't
require having to choose to pin the features abi but it is not
available yet.

> I'd also argue that treating this as a regression might possibly
> encourage better co-ordination in future.
> 
> James
>