Ubuntu 16.04: read access incorrectly implies 'm' rule

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."