Ubuntu 16.04: read access incorrectly implies 'm' rule

Bug #1838090 reported by Nathan Crandall on 2019-07-26
This bug report is a duplicate of:  Bug #1658219: flock not mediated by 'k'. Edit Remove
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
John Johansen

Bug Description

I've already been corresponding with jjohansen privately via email on this, filing a bug here based on our conversation. To summarize the email thread:

I was poking around some stuff today, and noticed that it seems like the 'm' rule doesn't actually do anything. I've tested this on two separate machines, both running Ubuntu 16.04:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial


$ sudo dmesg -c
$ cp /bin/ls /tmp
$ echo "/tmp/ls {
> /** r,
> }" > /tmp/tmp.ls
$ sudo apparmor_parser -C -r /tmp/tmp.ls
$ /tmp/ls
$ sudo dmesg
[1746349.392925] audit: type=1400 audit(1562018298.880:81): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/tmp/ls" pid=28205 comm="apparmor_parser"

There are no "ALLOWED" messages stating that we're missing the necessary "mr," rule for mmap'ing shared objects such as libc.

As a follow-up, even with an empty profile running in complain mode, I do not see any mention of needing the 'm' rule in the requested / denied mask, it just asks for read access:

[1748198.369441] audit: type=1400 audit(1562020148.006:82): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/tmp/ls" pid=28677 comm="apparmor_parser"
[1748203.023838] audit: type=1400 audit(1562020152.662:83): apparmor="ALLOWED" operation="open" profile="/tmp/ls" name="/etc/ld.so.cache" pid=28678 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[1748203.023877] audit: type=1400 audit(1562020152.662:84): apparmor="ALLOWED" operation="open" profile="/tmp/ls" name="/lib/x86_64-linux-gnu/libselinux.so.1" pid=28678 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[1748203.023945] audit: type=1400 audit(1562020152.662:85): apparmor="ALLOWED" operation="open" profile="/tmp/ls" name="/lib/x86_64-linux-gnu/libc-2.23.so" pid=28678 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[1748203.023998] audit: type=1400 audit(1562020152.662:86): apparmor="ALLOWED" operation="open" profile="/tmp/ls" name="/lib/x86_64-linux-gnu/libpcre.so.3.13.2" pid=28678 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[1748203.024039] audit: type=1400 audit(1562020152.662:87): apparmor="ALLOWED" operation="open" profile="/tmp/ls" name="/lib/x86_64-linux-gnu/libdl-2.23.so" pid=28678 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[1748203.024076] audit: type=1400 audit(1562020152.662:88): apparmor="ALLOWED" operation="open" profile="/tmp/ls" name="/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=28678 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

I tested this on Ubuntu 12.04, 18.04, and 19.04, and the expected behavior is indeed there. Seems like a regression in specifically 16.04.

Response from jjohansen:

"This bug was fixed in Ubuntu in the Ubuntu zesty kernel (4.10) but the fix was for a different issue and never cherry-picked back to Xenial. We are going to need a bug report to get this fixed in the Xenial kernel. So please do file a bug report. I can then attach the patch and send it to the kt for inclusion in the next SRU."

John Johansen (jjohansen) wrote :

Not a bug in upstream apparmor, only affects Ubuntu Xenial kernel

Changed in linux (Ubuntu Xenial):
status: New → Confirmed
assignee: nobody → John Johansen (jjohansen)
Changed in apparmor:
status: New → Invalid
information type: Private Security → Public Security

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-xenial
daniel CURTIS (anoda) wrote :


I would like to note, that when Linux kernel has been updated to 4.4.0-160.188 version[1] (with, among others, patches for LP:#1658219 and LP:#1838090), I've had to update a few profiles (such as Audacious, Parole, Xorg, Logrotate etc.), because of a lot of "DENIED" entries in system log files. If it's about access controls (vide 'requested{denied}_mask'): most new rules required 'm' (memory map as executable), but some of them needed 'k' (file locking) etc.)

However, it seems everything is okay now and I hope, that there will be no such issues anymore. Anyway, Mr Tyler Hicks was right: "users with custom policy have some reasonable expectation that upgrading to the new Ubuntu release or kernel version will require them to update their custom policy".

By the way; what is an impact of these changes? (I mean LP:#1658219 and LP:#1838090). Does it means, that now, use of 'm' and 'k' access is secured/restricted/checked correctly by AppArmor? And one more thing: this problem is related to v4.4 kernel only, right?

Thanks, best regards.
[1] https://launchpad.net/ubuntu/+source/linux/4.4.0-160.188

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

Other bug subscribers