mount rules grant excessive permissions

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.

This was assigned CVE-2016-1585

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

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

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

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.

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 :/

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

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

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

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

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

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.

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

So, jammy is still vulnerable to that.

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

Thanks a lot, John!

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

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

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.

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.

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.

I've been running this update on Jammy since 2024-04-18 with no visible side effect:

$ zgrep -w1 apparmor /var/log/apt/history.log.2.gz
Start-Date: 2024-04-18 12:48:18
Commandline: apt install apparmor/jammy-proposed
Requested-By: sdeziel (1000)
Upgrade: apparmor:amd64 (3.0.4-2ubuntu2.3, 3.0.4-2ubuntu2.4)
End-Date: 2024-04-18 12:48:25

I'll leave it to someone else to decide if that's enough to mark it as `verification-done-jammy`.