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

[Tyler Hicks]

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.

> +    elfmmap="m"
> +else
> +    elfmmap=""
> +fi
> +
>  # Verify file access and contexts by an unconfined process
>  runchecktest "EXEC_STACK (unconfined - file)" pass -f $file
>  runchecktest "EXEC_STACK (unconfined - otherfile)" pass -f $otherfile
> @@ -66,7 +72,7 @@
>  
>  # Verify file access and contexts by 2 stacked profiles
>  genprofile -I $fileok $sharedok $getcon $test:"ix -> &$othertest" -- \
> -	image=$othertest addimage:$test $otherok $sharedok $getcon $test:rm
> +	image=$othertest addimage:$test $otherok $sharedok $getcon $test:r$elfmmap

The previous change (r3509) simply added 'm' to the existing '$test r,'
rules but this patch description says, "this breaks the exec_stack test
for kernel pre 4.8." Is it true that adding 'm' actually broke the tests
in pre 4.8 or are you just trying to make the tests more accurate?

Tyler

>  runchecktest_errno EACCES "EXEC_STACK (2 stacked - file)" fail -- $test -f $file
>  runchecktest_errno EACCES "EXEC_STACK (2 stacked - otherfile)" fail -- $test -f $otherfile
>  runchecktest_errno EACCES "EXEC_STACK (2 stacked - thirdfile)" fail -- $test -f $thirdfile
> @@ -79,7 +85,7 @@
>  # Verify file access and contexts by 3 stacked profiles
>  genprofile -I $fileok $sharedok $getcon $test:"ix -> &$othertest" -- \
>  	image=$othertest addimage:$test $otherok $sharedok $getcon $test:"rix -> &$thirdtest" -- \
> -	image=$thirdtest addimage:$test $thirdok $sharedok $getcon $test:rm
> +	image=$thirdtest addimage:$test $thirdok $sharedok $getcon $test:r$elfmmap
>  runchecktest_errno EACCES "EXEC_STACK (3 stacked - file)" fail -- $test -- $test -f $file
>  runchecktest_errno EACCES "EXEC_STACK (3 stacked - otherfile)" fail -- $test -- $test -f $otherfile
>  runchecktest_errno EACCES "EXEC_STACK (3 stacked - thirdfile)" fail -- $test -- $test -f $thirdfile
> @@ -89,7 +95,7 @@
>  
>  genprofile -I $sharedok $stackotherok $stackthirdok $test:"rix -> &$othertest" -- \
>  	image=$othertest addimage:$test $sharedok $stackthirdok $test:"rix -> &$thirdtest" -- \
> -	image=$thirdtest addimage:$test $sharedok $stackthirdok $test:rm
> +	image=$thirdtest addimage:$test $sharedok $stackthirdok $test:r$elfmmap
>  # Triggered an AppArmor WARN in the initial stacking patch set
>  runchecktest "EXEC_STACK (3 stacked - old AA WARN)" pass -p $othertest -- $test -p $thirdtest -f $sharedfile
>  
> @@ -120,7 +126,7 @@
>  
>  # Verify file access and contexts in mixed mode
>  genprofile -I $fileok $sharedok $getcon $test:"ix -> &$othertest" -- \
> -	image=$othertest flag:complain addimage:$test $otherok $sharedok $getcon $test:rm
> +	image=$othertest flag:complain addimage:$test $otherok $sharedok $getcon $test:r$elfmmap
>  runchecktest "EXEC_STACK (mixed mode - file)" pass -- $test -f $file
>  runchecktest_errno EACCES "EXEC_STACK (mixed mode - otherfile)" fail -- $test -f $otherfile
>  runchecktest "EXEC_STACK (mixed mode - sharedfile)" pass -- $test -f $sharedfile
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20161004/c40dbf31/attachment.pgp>