Re: [apparmor] Interesting mmap denies for /tmp/# produces by libpcre2
On Tue, Jan 29, 2019 at 08:25:04PM +0200, Vincas Dargis wrote: > 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 > 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..? I believe you're right; I reviewed this code just a few days ago: https://sources.debian.org/src/pcre2/10.32-3/src/sljit/sljitProtExecAllocator.c/?hl=2#L143 > 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..? Ideally, some future AppArmor work will allow us to keep these separate. In the meantime we're probably better off allowing the accesses. Afterall, denying them means you won't get the benefit of the JIT, and the error-handling code in the processes in question may not be particularly well tested. If it exists at all. The code uses TMPDIR to discover where to put the files. This is both good and bad. You can leverage it to put the files elsewhere if you want, but users with unexpected settings could get failures that we don't see. Thanks signature.asc Description: PGP signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] Interesting mmap denies for /tmp/# produces by libpcre2
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 ``` Breakpointing on `openat` opening `/tmp` shows this: ``` Thread 1 "qtox" hit Catchpoint 1 (call to syscall openat), 0x7f8d5b9a844e in open64 () from /lib64/libpthread.so.0 $7 = 0x7fffad3cf5a0 "/tmp" #0 0x7f8d5b9a844e in open64 () from /lib64/libpthread.so.0 #1 0x7f8d5646994c in ?? () from /usr/lib64/libpcre2-16.so.0 #2 0x7f8d56469a83 in ?? () from /usr/lib64/libpcre2-16.so.0 #3 0x7f8d56497ff8 in ?? () from /usr/lib64/libpcre2-16.so.0 #4 0x7f8d5649929d in pcre2_jit_compile_16 () from /usr/lib64/libpcre2-16.so.0 #5 0x7f8d5c25383f in ?? () from /usr/lib64/libQt5Core.so.5 #6 0x7f8d5c253a5f in ?? () from /usr/lib64/libQt5Core.so.5 #7 0x7f8d5c25404c in QRegularExpression::isValid() const () from /usr/lib64/libQt5Core.so.5 #8 0x7f8d5c22a539 in QString::replace(QRegularExpression const&, QString const&) () from /usr/lib64/libQt5Core.so.5 #9 0x560df8b25b50 in Style::resolve(QString const&, QFont const&) () #10 0x560df8b24af6 in Style::getStylesheet(QString const&, QFont const&) () #11 0x560df8b1b637 in LoginScreen::LoginScreen(QString, QWidget*) () #12 0x560df8ac47cf 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(/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(/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(/tmp) offset=0 274563 19:49:01.289688475 6 qtox (6270) < mmap res=FFF3 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(/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
