Comment 0 for bug 1584069

As it stands today, all exec transitions triggered by a change_profile rule cause the AT_SECURE flag in the auxiliary vector to be set due to the kernel function apparmor_bprm_secureexec() returning 1 while setting up the execution environment. This causes libc to always scrub the environment variables during such an exec transition.

There should be a way to indicate, in the policy language, that AT_SECURE should not be triggered. This would be equivalent to the file rule type having the Px permission to trigger AT_SECURE and the px permission to not trigger it. The file rule type even has an 'unsafe' modifier keyword that could be reused as the change_profile modifier keyword.

Steps to show that AT_SECURE is being set:

# Build a test program to dump the AT_SECURE flag
$ cat <<EOF > print_at_secure.c
> #include <stdio.h>
> #include <sys/auxv.h>
>
> int main(void)
> {
> printf("AT_SECURE = %lu\n", getauxval(AT_SECURE));
> return 0;
> }
> EOF
$ gcc -o print_at_secure print_at_secure.c

# Load the test profile that allows all file accesses and any change_profile operations
$ echo "profile test { file, change_profile, }" | sudo apparmor_parser -qr

# Run bash under the test profile
$ aa-exec -p test -- bash

# Show the AT_SECURE is not set on exec
$ ./print_at_secure
AT_SECURE = 0

# Set up an exec transition (change_profile from the test profile back to the test profile)
$ echo "exec test" > /proc/self/attr/exec

# See that AT_SECURE is now set on exec
$ ./print_at_secure
AT_SECURE = 1