Upcoming AppArmor Security update for CVE-2016-1585

Security
,
1

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:

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).

5 Likes
2

As we are progressing towards of having this update released, the security team is carefully trying to get everything ready. One of the things was to prepare a no-change rebuild of the current versions in the respective updates pockets to the security pocket:

And that was done so the version in proposed could be published first in the updates pocket, but leaving people who experience possible issues the opportunity for an easy downgrade path to the prior version, via:

apt install apparmor/jammy-security

or

apt install apparmor/focal-security
1 Like
3

The AppArmor updates were published to jammy-updates and focal-updates earlier this week. The intent is to publish them to the respective security pockets next week.

Thanks!