mount rules grant excessive permissions

Bug #1597017 reported by John Johansen
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
AppArmor
New
Undecided
Unassigned

Bug Description

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

Tags: aa-parser

CVE References

Revision history for this message
John Johansen (jjohansen) wrote :

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.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This was assigned CVE-2016-1585

Christian Boltz (cboltz)
tags: added: aa-parser
Revision history for this message
Christian Boltz (cboltz) 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.)

Revision history for this message
John Johansen (jjohansen) wrote : Re: [Bug 1597017] Re: mount rules grant excessive permissions

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

Revision history for this message
Markus Koschany (apoleon) wrote :

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

Revision history for this message
intrigeri (intrigeri) wrote :

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.

Revision history for this message
Simon Déziel (sdeziel) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.