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
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Undecided
Unassigned
linux (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
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

PoC:

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

Hello.

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