Introduction

AppArmor exec rules allows specifying whether an exec transition should sanitize the environment of potentially dangerous variables such as LD_PRELOAD and LD_LIBRARY path. Currently AppArmor does this through the secure exec flag that is passed to libc and relies on the userspace loader to do the sanitization.

Unfortunately the loader only sanitizes unsafe environment variables for the loader does NOT take into account unsafe environment variables for applications, or interpreters. This can result in a by-pass for some of apparmor's protections. To help mitigate this problem the sanitized_helper profile was developed.

The issue/bypass

How the sanitized_helper works

Proper solution

The proper solution is to have AppArmor do the environment sanitization. Either by having AppArmor do the sanitization in the kernel or having it hi-jack the loader and redirect to an AppArmor specific loader that handles sanitization before transitioning to the real loader.

The set of environment variables that need to be filtered varies by application, and neither AppArmor nor the kernel can know in advance what this set is. This means that AppArmor needs to be extended to support a set of environment filtering rules that can be updated and applied via policy.

The rules need to be able to be used at exec time via attachment and via transition rules to handle situations where santization should be applied but profiles are shared and should not be changed.

See AppArmor environment scrubbing for further details.

????

Ux clears potentially harmful environment variables such as LD_PRELOAD and LD_LIBRARY_PATH (and others). Because it doesn't clear out all variables that can influence child processes, the confined parent process may have too much influence over the child. When considering GUI applications such as those based on gtk, child processes can also be called with --gtk-module.

Since there are several applications in the ubuntu-specific abstractions that can be affected in this manner, evince, firefox, the chromium profile as included in apparmor-profiles and the ubuntu-specific abstractions themselves should be adjusted to address this issue. Cups is also affected because of its use of Ux with filters, however it runs these filters as non-root and the environment under which these filters is run is more tightly controlled. Cups should be investigated more and we should consider confining (at least) those filters that we ship in Ubuntu.

Lenient profile that is intended to be used when 'Ux' is desired but does not provide enough environment sanitizing. This effectively is an open profile that blacklists certain known dangerous files and also does not allow any capabilities. For example, it will not allow 'm' on files owned be the user invoking the program. While this provides some additional protection, please use with care as applications running under this profile are effectively running without any AppArmor protection. Use this profile only if the process absolutely must be run (effectively) unconfined.

Limitations:
1. This does not work for root owned processes, because of the way we use
   owner matching in the sanitized helper. We could do a better job with
   this to support root, but it would make the policy harder to understand
   and going unconfined as root is not desirable any way.

2. For this sanitized_helper to work, the program running in the sanitized
   environment must open symlinks directly in order for AppArmor to mediate
   it. This is confirmed to work with:
    - compiled code which can load shared libraries
    - python imports
   It is known not to work with:
    - perl includes

3. Going forward it might be useful to try sanitizing ruby and java

Use at your own risk. This profile was developed as an interim workaround for

Originally tracked in Ubuntu bug