Hi,
While developing some profile, I've discovered spam of denies:
```
type=AVC msg=audit(1548784267.275:2162): apparmor="DENIED" operation="file_mmap" profile="qtox"
name="/tmp/#13288" pid=6316 comm="qtox" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
type=AVC msg=audit(1548784267.283:2163): apparmor="DENIED" operation="file_mmap" profile="qtox"
name="/tmp/#13289" pid=6316 comm="qtox" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
type=AVC msg=audit(1548784267.291:2164): apparmor="DENIED" operation="file_mmap" profile="qtox"
name="/tmp/#13290" pid=6316 comm="qtox" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
<and so on>
```
Breakpointing on `openat` opening `/tmp` shows this:
```
Thread 1 "qtox" hit Catchpoint 1 (call to syscall openat), 0x00007f8d5b9a844e in open64 () from
/lib64/libpthread.so.0
$7 = 0x7fffad3cf5a0 "/tmp"
#0 0x00007f8d5b9a844e in open64 () from /lib64/libpthread.so.0
#1 0x00007f8d5646994c in ?? () from /usr/lib64/libpcre2-16.so.0
#2 0x00007f8d56469a83 in ?? () from /usr/lib64/libpcre2-16.so.0
#3 0x00007f8d56497ff8 in ?? () from /usr/lib64/libpcre2-16.so.0
#4 0x00007f8d5649929d in pcre2_jit_compile_16 () from
/usr/lib64/libpcre2-16.so.0
#5 0x00007f8d5c25383f in ?? () from /usr/lib64/libQt5Core.so.5
#6 0x00007f8d5c253a5f in ?? () from /usr/lib64/libQt5Core.so.5
#7 0x00007f8d5c25404c in QRegularExpression::isValid() const () from
/usr/lib64/libQt5Core.so.5
#8 0x00007f8d5c22a539 in QString::replace(QRegularExpression const&, QString const&) () from
/usr/lib64/libQt5Core.so.5
#9 0x0000560df8b25b50 in Style::resolve(QString const&, QFont const&) ()
#10 0x0000560df8b24af6 in Style::getStylesheet(QString const&, QFont const&) ()
#11 0x0000560df8b1b637 in LoginScreen::LoginScreen(QString, QWidget*) ()
#12 0x0000560df8ac47cf in main ()
```
And I believe these syscalls (sysdig output) are the culprit:
```
274389 19:49:01.289600874 6 qtox (6270) > openat
274463 19:49:01.289637563 6 qtox (6270) < openat fd=14(<d>/tmp) dirfd=-100(AT_FDCWD) name=/tmp
flags=5155(O_DIRECTORY|O_EXCL|O_RDWR|O_CLOEXEC) mode=0600
274468 19:49:01.289639473 6 qtox (6270) > ftruncate
274501 19:49:01.289656985 6 qtox (6270) < ftruncate
274504 19:49:01.289657730 6 qtox (6270) > mmap addr=0 length=65536 prot=3(PROT_READ|PROT_WRITE)
flags=1(MAP_SHARED) fd=14(<d>/tmp) offset=0
274525 19:49:01.289668928 6 qtox (6270) < mmap res=7F7BB43BD000 vm_size=501584
vm_rss=74788 vm_swap=0
274527 19:49:01.289669770 6 qtox (6270) > mmap addr=0 length=65536 prot=5(PROT_READ|PROT_EXEC)
flags=1(MAP_SHARED) fd=14(<d>/tmp) offset=0
274563 19:49:01.289688475 6 qtox (6270) < mmap res=FFFFFFFFFFFFFFF3 vm_size=501584 vm_rss=74788
vm_swap=0
274636 19:49:01.289730600 6 qtox (6270) > munmap addr=7F7BB43BD000 length=65536
274653 19:49:01.289742346 6 qtox (6270) < munmap res=0 vm_size=501520
vm_rss=76052 vm_swap=0
274659 19:49:01.289744480 6 qtox (6270) > close fd=14(<d>/tmp)
274662 19:49:01.289745731 6 qtox (6270) < close res=0
```
Interestingly, so far this reproduced only on openSUSE Tumbleweed (compared to Debian Sid, Ubuntu
18.04). Maybe only openSUSE libpcre is built with regex jitting or smth..?
Anyway, these /some/path/#number denies are kind.. slowly growing here and there. It would be nice
to have some way to tackle them explicitly in AppArmor policy files. For now, I would probably deny
mmaping /tmp/#[0-9][0.... as application seems to work fine so far.
Maybe library developers could implement these mmaps "differently" to avoid
"problems" with MACs?
Or we "just" need some new rules to handle these cases that becomes more
"popular" with time..?
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
