mount rules grant excessive permissions

[John Johansen]

SRU Team; the packages for focal-proposed and jammy-proposed are intended as security updates prepared by the Ubuntu Security team (and have built in a ppa with only the security pockets enabled). However, because the fix makes mount rules in apparmor policy be treated more restrictively than they were prior to this update, we would like these packages to gain more widespread testing.

Risk of Regression:

The update for this issue causes the apparmor parser, the tool that translates written policy into the enforcement data structures used by the kernel, to generate more strict policy for mount rules, like the example below. They are not common in apparmor policy generally, but can appear in policies written for container managers to restrict containers, and thus can potentially break container startup.

The packages prepared for focal-proposed and jammy-proposed have tested with the versions of snapd, lxc, libvirt, and docker in the ubuntu archive, but container managers outside of the ubuntu archive may run into issues, hence the need for testing and policy adjustments.

Original Report:

The rule
  mount options=(rw,make-slave) -> **,

ends up allowing
  mount -t proc proc /mnt

which it shouldn't as it should be restricted to commands with a make-slave flag

[John Johansen (jjohansen)]

The parser is generating 2 match rules in the dfa off of the one text rule, they are the equivalent of
  mount options=(rw,make-slave) -> **,
  mount options=rw,

this is due to how the parser is trying to share rule generation for generic rules that don't specify a flag, and rules that specify them. When flags aren't specified multiple rule sets may need to be generated but only one matching the flags should when the flags are specified.

[Marc Deslauriers (mdeslaur)]

This was assigned CVE-2016-1585

[Christian Boltz (cboltz)]

Now that support for mount rules is on their way to the upstream kernel - any news on this?

(For the records: https://bugzilla.opensuse.org/show_bug.cgi?id=995594 is the openSUSE twin of this bugreport, and was just closed today because the openSUSE kernel doesn't support mount rules.)

[John Johansen (jjohansen)]

On 07/13/2017 09:39 AM, Christian Boltz wrote:
> Now that support for mount rules is on their way to the upstream kernel
> - any news on this?
>
> (For the records: https://bugzilla.opensuse.org/show_bug.cgi?id=995594
> is the openSUSE twin of this bugreport, and was just closed today
> because the openSUSE kernel doesn't support mount rules.)
>
> ** Bug watch added: bugzilla.opensuse.org/ #995594
> https://bugzilla.opensuse.org/show_bug.cgi?id=995594
>

I have a wip patch, but it hasn't been a priority lately. I do plan
on finishing up with it soon but atm the 4.13 backports for suse
are the current higher priority item blocking completion

[Markus Koschany (apoleon)]

Hello,

this is an old bug report but due to the assigned CVE it still shows up in Debian's security tracker.

https://security-tracker.debian.org/tracker/CVE-2016-1585

Could someone elaborate on if and when this bug was resolved and point to relevant fixing commits. Any information about the nature of this bug and its impact on current Debian and Ubuntu releases would be appreciated.

Regards,

Markus

[intrigeri (intrigeri)]

I was asked by a Debian security team member to share how much this is a concern for Debian. I'll do that here, even though this might be irrelevant for other distros, in the hope more knowledgeable folks can correct whatever I got wrong :)

The Debian Stretch kernel does not support mount rules so it's out of scope, except for users running a kernel from backports.

The Debian Buster kernel supports mount rules. AFAIK only two things use mount rules in Debian:

* LXC: not a regression, since we've never confined LXC with AppArmor by default before Buster and Stretch's kernel has no support for mount rules IIRC; worst case, LXC guests on a Buster host are less strictly confined than we would like, which would be nice to fix, but we were very close to disable AppArmor for LXC during the freeze, so well.
* libvirtd: no big deal, this profile is not meant to be a strong security boundary (libvirtd can do so much anyway), but rather as a way to start processes run by libvirtd under their own profile.

Adding to this that John discovered this almost 3y ago and did not prioritize fixing it, I would categorize this issue as unimportant for now in the context of Debian.

[Simon Déziel (sdeziel)]

I'm coming from https://github.com/lxc/lxd/issues/6799 where daemons inside containers are unable to get proper mount namespace setup due to what seems like an Apparmor bug (this one?).

Starting systemd-networkd inside a container (foo) will generate this:

 apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-foo_</var/snap/lxd/common/lxd>" name="/run/systemd/unit-root/" pid=2338 comm="(networkd)" flags="ro, remount, noatime, bind"

this causes the entire FS tree as seen by systemd-networkd to remain read-write and visible. This is despite having the following restrictions supposedly applied:

  $ systemctl cat systemd-networkd | grep -E 'Protect(Home|System)'
  ProtectSystem=strict
  ProtectHome=yes

ProtectSystem is supposed to have everything remounted as read-only and ProtectHome is supposed to make /home and /root inaccessible. None of this works and I find it worrying :/

[Aleksandr Mikhalitsyn (mihalicyn)]

Let it be there
https://gitlab.com/apparmor/apparmor/-/merge_requests/994

Merged:
https://gitlab.com/apparmor/apparmor/-/merge_requests/333

[John Johansen (jjohansen)]

The initial fixed was released in
apparmor 3.1.4
apparmor 3.0.10
apparmor 2.13.8

there were two sets of followup releases to deal with regression issues
apparmor 3.1.5, 3.0.11, 2.13.9

and finally
apparmor 3.1.6 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.1.6
apparmor 3.0.12 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0.12
apparmor 2.13.10 https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_2.13.10

[Aleksandr Mikhalitsyn (mihalicyn)]

Dear colleagues,

can you clarify when this updated AppArmor version appear in Ubuntu 22.04?
As I can see from https://packages.ubuntu.com/jammy/apparmor version is still AppArmor 3.0.4.

Kind regards,
Alex

[John Johansen (jjohansen)]

@mihalicyn: Ubuntu does not generally updated to newer package versions during the life of a release. Instead they will backport fixes to the package version in the release. So 22.04 will remain on AppArmor 3.0.4 when the fixes land, but the Ubuntu version will change.

I can not say when the fix will land in Ubuntu 22.04 at this time but the backport and testing work is in progress.

[Aleksandr Mikhalitsyn (mihalicyn)]

Gentle ping.

JFYI: in the next LXC release 5.0.4 we will get a real security issue because of that, because we have merged a fix to make privileged containers to work (when new systemd is used).

https://github.com/lxc/lxc/pull/4295

Can we fix that in Jammy? We have everything for that we just need to backport the fix to Jammy and issue a new release of the package.

[Aleksandr Mikhalitsyn (mihalicyn)]

https://changelogs.ubuntu.com/changelogs/pool/main/a/apparmor/apparmor_3.0.4-2ubuntu2/changelog

So, jammy is still vulnerable to that.

[John Johansen (jjohansen)]

The mount fixes were backported to Jammy, AFAIK the only thing that was remaining to be done was publish them to the security pocket and publish the USN. I will look into where this is at

[Aleksandr Mikhalitsyn (mihalicyn)]

Thanks a lot, John!

[Marc Deslauriers (mdeslaur)]

FYI This is now in the jammy and focal upload queues to go to -proposed.

[Achraf Merzouki (achraf-mer)]

Hello,

A gentle ping on this issue, it still shows up on jammy security report and looks like 2ubuntu2.3 here https://changelogs.ubuntu.com/changelogs/pool/main/a/apparmor/apparmor_3.0.4-2ubuntu2.3/changelog doesn't have the fix.

@jjohansen can we please advise on when the fix will be backported to ubuntu 22.04? thanks

[John Johansen (jjohansen)]

It is in the SRU queue and the current ETA is April 15 to land in the proposed pocket (archive proposed not security proposed ppa), there is a caveat that the recent xz backdoor has caused some "fun" on the archive side and could potentially cause some delays.

[Brian Murray (brian-murray)]

Hello John, or anyone else affected,

Accepted apparmor into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/3.0.4-2ubuntu2.4 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 on 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, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello John, or anyone else affected,

Accepted apparmor into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu5.4 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 on 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, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.