apparmor: no working rule to allow making a mount private

Bug #1350947 reported by Martin Pitt
66
This bug affects 7 people
Affects Status Importance Assigned to Milestone
AppArmor
Invalid
Medium
Unassigned
lxc (Ubuntu)
Fix Released
High
Stéphane Graber

Bug Description

NOTE: This bug will be fixed with an update to lxc. However, two AppArmor bugs (bug #1401619 and bug #1401621) were identified as a result of triaging this bug and they will both be fixed in upstream AppArmor.

When the file system is mounted as MS_SHARED by default (such as under systemd, or when the admin configures it so), things like schroot or LXC need to make their "guest" mounts private. This currently fails under utopic:

$ sudo lxc-create -t busybox -n c1
$ sudo mount --make-rshared /
$ sudo strace -fvvs1024 -e mount lxc-start -n c1
[...]
[pid 10749] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission denied)
lxc-start: Permission denied - Failed to make / rslave

dmesg says:
audit: type=1400 audit(1406825005.687:551): apparmor="DENIED" operation="mo
unt" info="failed flags match" error=-13 profile="/usr/bin/lxc-start" name="/" pid=8228 co
mm="lxc-start" flags="rw, slave"

(This happens for all mount points on your system, I'm just showing the first one)

This will leave a couple of leaked mounts on your system. This is an useful rune to clean them up:

$ for i in 1 2 3; do sudo umount `mount|grep lxc|awk '{print $3}'`; done

(needs to be done several times; check with "mount |grep lxc" that it's clean)

I tried to allow that by adding this to /etc/apparmor.d/abstractions/lxc/start-container:

  mount options=(rw, slave) -> **,

then reload the policy and rety with

$ sudo stop lxc; sudo start lxc; sudo lxc-start -n c1

(and again clean up the mounts with above rune)

I tried some variations of this, like

  mount options in (rw, slave, rslave, shared, rshared) -> **,

but none of them worked. The only things that do work are one of

  mount,
  mount -> **,

but those are too lax to be an effective security restriction.

WORKAROUND
==========
(Attention: insecure! Don't use for production machines)

Add this to /etc/apparmor.d/abstractions/lxc/start-container:

   mount,

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-6-generic 3.16.0-6.11
ProcVersionSignature: Ubuntu 3.16.0-6.11-generic 3.16.0-rc7
Uname: Linux 3.16.0-6-generic x86_64
ApportVersion: 2.14.5-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: martin 1665 F.... pulseaudio
CurrentDesktop: Unity
Date: Thu Jul 31 18:58:18 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-02-27 (154 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140224)
MachineType: LENOVO 2324CTO
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-6-generic.efi.signed root=UUID=a2b27321-0b55-44c9-af0d-6c939efa45ce ro quiet splash init=/lib/systemd/systemd crashkernel=384M-:128M vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-6-generic N/A
 linux-backports-modules-3.16.0-6-generic N/A
 linux-firmware 1.132
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/09/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: G2ET95WW (2.55 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2324CTO
dmi.board.vendor: LENOVO
dmi.board.version: 0B98401 Pro
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG2ET95WW(2.55):bd07/09/2013:svnLENOVO:pn2324CTO:pvrThinkPadX230:rvnLENOVO:rn2324CTO:rvr0B98401Pro:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2324CTO
dmi.product.version: ThinkPad X230
dmi.sys.vendor: LENOVO

Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :

I tested this on trusty's 3.13.0-32, and the previous utopic 3.15.0-6, same result. So it's not a regression apparently; although I tried "mount options=(rw, slave) -> /" some weeks ago and it appeared to work, but apparently I did something weird back then which made it work, but I can't remember how any more.

tags: added: apparmor
description: updated
tags: added: systemd-boot
Changed in linux (Ubuntu):
assignee: nobody → John Johansen (jjohansen)
status: New → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

Adding an LXC task; after we figure out how the rule needs to look like/fixing the apparmor parser or linux bug, we need to adjust LXC's apparmor policy. This was originally bug 1325468, but it's easier to have it in one bug.

Changed in lxc (Ubuntu):
status: New → Triaged
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti)
description: updated
Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1350947] Re: apparmor: no working rule to allow making a mount private

Note this is more important than leaking a few mounts - it will also cause
breakage if using both "ip netns" and lxc.

Revision history for this message
Martin Pitt (pitti) wrote :

Setting to incomplete for now. This either needs fixing in AppArmor properly, or I at least need to get some hints how to change the current rule to work with current AppArmor.

Changed in lxc (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

 affects: apparmor

Changed in apparmor:
importance: Undecided → Medium
status: New → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → Medium
Changed in lxc (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Apparmor is recognizing "make-slave', not "slave". While apparmor will be updated to accept 'slave' we should update the lxc policies to use 'make-slave' in the meantime.

Assigning this to Stéphane as he hasn't yet had a chance to show me the new
git-dpm packaging process :)

Changed in lxc (Ubuntu):
status: Incomplete → Triaged
assignee: Martin Pitt (pitti) → Stéphane Graber (stgraber)
Revision history for this message
Tyler Hicks (tyhicks) wrote :

As a result of the "slave" versus "make-slave" revelation, I've created two upstream AppArmor bugs. The first is for the AppArmor documentation being wrong about the acceptable mount option strings (bug #1401619). The second is for the AppArmor parser accepting unknown mount option strings (bug #1401621).

Since the fix for this specific bug will come as an lxc update, I'm going to mark the AppArmor tasks in this bug as invalid and use the two bugs mentioned above.

Changed in apparmor:
status: Confirmed → Invalid
Changed in linux (Ubuntu):
status: Confirmed → Invalid
description: updated
James Page (james-page)
tags: added: smoosh
Revision history for this message
James Page (james-page) wrote :

Bumped priority for this bug as this is part of priority activity for reference OpenStack deployments for the vivid cycle .

Changed in lxc (Ubuntu):
importance: Medium → High
Changed in linux (Ubuntu):
importance: Medium → High
tags: added: landscape
Revision history for this message
Martin Pitt (pitti) wrote :

I confirm that this works fine under systemd:

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

Thanks!

tags: added: canonical-bootstack
Revision history for this message
Martin Pitt (pitti) wrote :

I created an upstream patch and a pull request at https://github.com/lxc/lxc/pull/393

Changed in lxc (Ubuntu):
status: Triaged → Fix Committed
Martin Pitt (pitti)
no longer affects: linux (Ubuntu)
Revision history for this message
Martin Pitt (pitti) wrote :

This fix is contained in the latest lxc in vivid now.

Changed in lxc (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Junien F (axino) wrote :

Hi Serge, Martin,

As Serge mentioned in #4, this bug will cause breakage if using both "ip netns" and lxc. As I'm sure you're aware, the OpenStack neutron/quantum gateway makes heavy use of the "ip netns" feature, and it's valid to have LXC containers on the server hosting tje quantum gateway.

Given this setup, adding a container to the server hosting the quantum gateway breaks the netns for the DHCP and L3 agents, which leads to all sorts of fun.

So, does it make sense to backport this fix to trusty ? If not, then is manually applying https://github.com/lxc/lxc/pull/393/files a valid workaround ?

Thanks !

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Yup, it does - as stgraber mentioned on irc, this will be included in 1.0.8

Revision history for this message
JuanJo Ciarlante (jjo) wrote :

FYI I'm able to successfully drive netns inside LXC, manually then also
via openstack neutron-gateways, via this crafted aa profile:
/etc/apparmor.d/lxc/lxc-default-with-netns ->
https://gist.github.com/jjo/ff32b08e48e4a52bfc36

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.