incorrect file mediation with chroot to merged overlayfs directory in a subdir of a directory with full access

Bug #1703692 reported by Jamie Strandboge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
New
Undecided
Unassigned

Bug Description

The summary is rather long, but the problem arises when the merged directory of an overlayfs mount is under another directory that the application has full access to and we use '/' as the lowerdir and chroot into merged.

This simulates the situation of something like schroot that wants a readonly '/' with all writes handled by overlay, but the merged mountpoint happens to be under a directory that schroot has full access to.

This also simulates what might happen in snappy if we allowed overlayfs in an interface. Because the snap has limited write areas (eg, COMMONDIR below), it would create a mountpoint in one of them (eg, TOPDIR as a subdir of COMMONDIR, below). If the snap used (and policy allowed it) '/' as the lower dir and did a chroot onto merged, then the snap could access files in / that it shouldn't.

Eg

@{TESTDIR}="/tmp/tmp.sQqTm4RqpW/data"
@{COMMONDIR}="/tmp/tmp.sQqTm4RqpW/common"
@{TOPDIR}="/tmp/tmp.sQqTm4RqpW/common/mnt"

# merged/ is under COMMONDIR and because we give full access to COMMONDIR, the
# following alias rule ends up granting access to files in / as if they were in
# COMMONDIR (directories are correctly mediated)
alias / -> /tmp/tmp.sQqTm4RqpW/common/mnt/merged/,

profile test-profile (attach_disconnected) {
...
  # full access to COMMONDIR
  @{COMMONDIR}/ rw,
  @{COMMONDIR}/** rwklix,
...
  mount fstype=overlay overlay -> @{TOPDIR}/merged/,
}

Notice that there are no rules for @{TOPDIR}/merged in the policy. With the above, directories are properly mediated, but file and exec rules are not.

Reproducer:
$ tar -zxvf ./overlay-with-chroot-and-alias-rules.tar.gz && sudo ./overlay-with-chroot-and-alias-rules/drv
overlay-with-chroot-and-alias-rules/
overlay-with-chroot-and-alias-rules/p.in
overlay-with-chroot-and-alias-rules/overlay.c
overlay-with-chroot-and-alias-rules/drv
overlay-with-chroot-and-alias-rules/tst
Created tmpdir '/tmp/tmp.sQqTm4RqpW'

Ubuntu 4.10.0-26.30-generic 4.10.17

Disabling kernel rate-limiting
kernel.printk_ratelimit = 0

Loading /tmp/tmp.sQqTm4RqpW/data/p

chdir(/tmp/tmp.sQqTm4RqpW/common/mnt)

Creating the overlay directories
- mkdir /tmp/tmp.sQqTm4RqpW/common/mnt/lower
- mkdir /tmp/tmp.sQqTm4RqpW/common/mnt/upper
- mkdir /tmp/tmp.sQqTm4RqpW/common/mnt/work
- mkdir /tmp/tmp.sQqTm4RqpW/common/mnt/merged

Populating /tmp/tmp.sQqTm4RqpW/common/mnt/lower
- /tmp/tmp.sQqTm4RqpW/common/mnt/lower/test-lower

Populating /tmp/tmp.sQqTm4RqpW/common/mnt/upper
- /tmp/tmp.sQqTm4RqpW/common/mnt/upper/test-upper

Creating /tmp/tmp.sQqTm4RqpW/common/mnt/scratch

Perform the overlay
lower=/
upper=/tmp/tmp.sQqTm4RqpW/common/mnt/upper
work=/tmp/tmp.sQqTm4RqpW/common/mnt/work
where=/tmp/tmp.sQqTm4RqpW/common/mnt/merged
exe=/tmp/tmp.sQqTm4RqpW/data/tst
- mount('overlay', '/tmp/tmp.sQqTm4RqpW/common/mnt/merged', 'overlay', MS_MGC_VAL, lowerdir=/,upperdir=/tmp/tmp.sQqTm4RqpW/common/mnt/upper,workdir=/tmp/tmp.sQqTm4RqpW/common/mnt/work
 - success
- chdir('/tmp/tmp.sQqTm4RqpW/common/mnt/merged')
 - success
- chroot('.')
 - success
starting '/tmp/tmp.sQqTm4RqpW/data/tst'

Test /etc (expect denied dir)
ls: cannot open directory '/etc': Permission denied

Test /etc/shadow (expect denied file read)
daemon:*:17268:0:99999:7:::
FAIL: could access /etc/shadow

Test netstat --version (expect denied exec)
/tmp/tmp.sQqTm4RqpW/data/tst: line 23: netstat: command not found

Cleaning up
- umount /tmp/tmp.sQqTm4RqpW/common/mnt/merged
- rm -rf /tmp/tmp.sQqTm4RqpW

The fact that directories are properly mediated here and that upper and lower rules are needed in bug #1703674 for directories makes me think that this bug and bug #1703674 may be related.

Tags: aa-kernel
description: updated
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :
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.