When mediation of mount syscall operations was added to AppArmor, the translation of written policy into data structures for use by the Linux kernel to enforce mount restrictions was flawed, resulting in looser permissions than was intended by policy. This could possibly allow an attacker to bypass AppArmor restrictions in a confined application where some mount operations were permitted; policies that do not allow any mount operations are not affected. This issue was assigned CVE-2016-1585.
We will be addressing this issue with a security update for the AppArmor userspace utilities for Ubuntu 22.04 LTS (jammy) and Ubuntu 20.04 LTS (focal) that perform this translation of policy. However, because this will result in existing policies that make use of mount permissions being enforced more strictly, this may result in applications confined by such policies to be prevented from performing mount operations that they previously were allowed to do. Most applications confined by AppArmor do not need to perform mount operations and as such, their policies will not contain any rules allowing mount operations and are thus unaffected by this issue. However, this update may have a particular impact on container managers where mount policies are commonly used. Therefore we will be making this update available for testing in the proposed pockets for each affected release so that they are available for testing in environments where mount permissions are used in AppArmor policy.
Versions in the Ubuntu proposed pockets:
- Jammy: 3.0.4-2ubuntu2.4
- Focal: 2.13.3-7ubuntu5.4
To install the apparmor package for testing, enable the appropriate proposed archive (jammy-proposed or focal-proposed), update your apt metadata information, and then do:
apt install apparmor/jammy-proposed
or
apt install apparmor/focal-proposed
as appropriate.
Identifying potential affected AppArmor policies
AppArmor rules that might be affected begin with the keyword mount and some options (a bare mount keyword allows all mount operations in the policy); an example rule might look like:
mount options=(rw,make-shared) -> **,
Searching for the mount keyword in /etc/apparmor.d/ can be helpful in identifying which applications might be affected. Please see the “Mount Rules” section in the apparmor.d(5) man
page for more details about mount policy rules and their syntax.
Running typical applications with the fixed AppArmor may turn up new AppArmor denials with the tighter policy generation; these rejections will show up either in the system logs or if the audit daemon is used, in audit logs.
Mount operation denial examples
An example of a new mount failure occurring when an instance of the virtual proc file system is prevented from being mounted on /tmp/mountpoint/:
Example command:
mount -t proc proc /tmp/mountpoint
Example denial log entry:
audit: type=1400 audit(1712821125.380:3499): apparmor="DENIED" operation="mount" info="failed perms check" error=-13 \
profile="an_application_profile" name="/tmp/mountpoint/" pid=84181 comm="mount" fstype="proc" srcname="proc"
This could be addressed by adding the following rule to the AppArmor policy:
mount fstype=proc -> /tmp/mountpoint/,
Do note that the trailing / is necessary when referring to the mount point directory.
Another example denial when attempting to bind mount a directory /var/application/data/ to an alternate location, /tmp/mountpoint/:
Example command:
mount -o rw,bind /var/application/data/ /tmp/mountpoint
Example denial log entry:
AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="an_application_profile" \
name="/tmp/mountpoint/" pid=229722 comm="mount" srcname="/var/application/data/" flags="rw, bind"
Possible AppArmor policy rule:
mount options=(rw,bind) /var/application/data/ -> /tmp/mountpoint/,
These are the type of log events that would indicate the policy needs to be updated. The policy must be reloaded before it will apply. Use apparmor_parser --replace for this, either individual policies with:
apparmor_parser --replace /etc/apparmor.d/an_application_profile
or all profiles in this directory with:
apparmor_parser --replace /etc/apparmor.d/
Timeline and Feedback
The apparmor packages are expected to be published to the security pockets during the week of April 22nd. Feedback is appreciated, either on this post or on the related bug report (LP: #1597017).