[apparmor] [patch] - fix exec_stack to work on pre 4.8 kernels

[John Johansen]

On 10/05/2016 07:36 AM, Tyler Hicks wrote:
> On 10/05/2016 02:46 AM, John Johansen wrote:
>> On 10/04/2016 07:32 PM, Tyler Hicks wrote:
>>> On 10/04/2016 06:31 PM, John Johansen wrote:
>>>> exec_stack picked up a fix to address a semantic change introduced in
>>>> 4.8 kernels. However this breaks the exec_stack test for kernel pre
>>>> 4.8. This patch uses an apparmor kernel flag to detect whether the
>>>> semantic change is present and adjusts the test accordingly.
>>>
>>> A couple questions below...
>>>
>>>>
>>>> ---
>>>>
>>>> === modified file 'tests/regression/apparmor/exec_stack.sh'
>>>> --- tests/regression/apparmor/exec_stack.sh	2016-09-29 04:11:29 +0000
>>>> +++ tests/regression/apparmor/exec_stack.sh	2016-10-04 21:15:48 +0000
>>>> @@ -43,6 +43,12 @@
>>>>  
>>>>  touch $file $otherfile $sharedfile $thirdfile
>>>>  
>>>> +if [ "$(kernel_features domain/fix_binfmt_elf_mmap)" == "true" ]; then
>>>
>>> Why is the kernel doing domain/fix_binfmt_elf_mmap instead of bumping
>>> the kABI? Maybe I'm misunderstanding the purpose of the kABI but I
>>> understood it to be bumped when there were was a change in mediation
>>> that causes policy change.
>>>
>>
>> For a few reasons.
>> 1. I brought up bumping the potential of bumping the abi and got no
>> feedback.
> 
> Sorry about that. I'm still trying to fully understand how kABI is
> intended to be used (I think I'm getting there now) so I don't know that
> I could have provided much feedback.
> 
>> 2. The abi bump here is odd in that it is kernel caused not apparmor.
>> That doesn't mean we don't bump the abi but it is less clear. Hence 1
>> 3. I am worried that the patch that introduced the semantic change
>> will show up in stable kernels as it is an information leak fix
>> for tracing. For none ubuntu kernels this will mean a different
>> abi on the apparmor side, so bumping the abi alone is problematic.
>> Ubuntu is at v7, while upstream is at v6. We can bump the abi to v8
>> but what do we do for upstream or other distro kernels? We can't
>> bump them to v7, nor v8 as they are missing other semantic changes.
> 
> Interesting and frustrating problem.
> 
>>
>> This is a case where a sub version would be nice.
>>
>> so with that issue in place so it can be properly detected and conditioned
>> in the regression tests. Since we can't currently tie it to a single
>> abi number.
>>
>> With that said I am still open to bumping to v8 for stacking based
>> kernels. But we need the flag to deal with v6 abi based kernels if
>> this ever happens.
>>
>> I am no also open to the idea of using one or two bits of the abi
>> for a sub version. So we can handle something like this better in the
>> future.
> 
> One or two bits doesn't seem like enough. If that's all that we have to
> spare, I think I would have chosen 'domain/fix_binfmt_elf_mmap', too.
> 
possibly. This has only happened a few times in the past so ideally it
would be enough between major abi bumps.

With that said, When wrote this I was thinking it would need to fit into
the current 11 bits used by policy loads to indicate the kabi that
policy is targeting.

I reality we could split this out into a separate number in which case
we could have as many bits as we wanted.