Hello Tyler, or anyone else affected, Accepted apparmor into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: apparmor (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1584069 Title: change_profile rules need a modifier to allow non-secureexec transitions Status in AppArmor: Fix Committed Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Xenial: Fix Committed Bug description: [Impact] Applications which use libapparmor's aa_change_onexec() to set up an AppArmor profile transition across an upcoming exec() cannot pre- initialize the environment. This is caused by AppArmor unconditionally setting the AT_SECURE flag on the process, causing libc to scrub the environment upon exec(). Upstream AppArmor and Yakkety now support policy language that allows the policy author to specify that the environment should not be scrubbed but the changes need to be SRU'ed to Ubuntu 16.04. [Test Case] The upstream changes include exhaustive tests for the new policy language keywords. Some of them are run at build time (the apparmor_parser tests) and all of them are run by QRT's test- apparmor.py (the apparmor_parser tests, the Python utility tests, and the kernel regression tests). If a manual test is desired, see the original report below for steps. [Regression Potential] Regression potential is considerable since the fixes add new keywords to the policy language. No kernel changes are required, which mitigates some of the risk. Additionally, as mentioned above, the upstream changes include many new tests to ensure that regressions are not introduced. [Original Report] 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 To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1584069/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
