mount rules grant excessive permissions

[John Johansen]

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