*** This bug is a duplicate of bug 1658219 ***
https://bugs.launchpad.net/bugs/1658219
** Information type changed from Private Security to Public Security
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1838090
Title:
Ubuntu 16.04: read access incorrectly implies 'm' rule
Status in AppArmor:
Invalid
Status in linux package in Ubuntu:
New
Status in linux source package in Xenial:
Confirmed
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."
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1838090/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
