[apparmor] Interesting mmap denies for /tmp/#<number> produces by libpcre2

[Seth Arnold]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190129/916558a5/attachment.sig>