This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2142791 - AVC on mmap() when executing "grep -P" and deny_execmem boolean is enabled
Summary: AVC on mmap() when executing "grep -P" and deny_execmem boolean is enabled
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.7
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-15 09:57 UTC by Renaud Métrich
Modified: 2023-09-11 07:08 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-09-02 01:00:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-2035 0 None Migrated None 2023-09-11 07:08:12 UTC
Red Hat Issue Tracker RHELPLAN-139370 0 None None None 2022-11-15 10:38:09 UTC

Description Renaud Métrich 2022-11-15 09:57:15 UTC 
Description of problem:

When SELinux boolean "deny_execmem" is enabled (which is not the default), any execution of "grep -P" leads to getting an AVC, as shown in the example below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# grep -P -o '^BOOT_IMAGE=(\S+)' /proc/cmdline

# ausearch -m avc -i -ts recent
...
type=PROCTITLE msg=audit(11/15/2022 10:26:05.953:257) : proctitle=grep --color=auto -P -o ^BOOT_IMAGE=(\S+) /proc/cmdline 
type=SYSCALL msg=audit(11/15/2022 10:26:05.953:257) : arch=x86_64 syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=12956 pid=15740 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=grep exe=/usr/bin/grep subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(11/15/2022 10:26:05.953:257) : avc:  denied  { execmem } for  pid=15740 comm=grep scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The root cause for this is "grep" internally calling libpcre's code which tries to execute code in memory:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
(gdb) bt
#0  0x00007f1db63a4af7 in mmap64 () from /lib64/libc.so.6
#1  0x00007f1db6670370 in alloc_chunk (size=65536) at sljit/sljitExecAllocator.c:213
#2  sljit_malloc_exec (size=936) at sljit/sljitExecAllocator.c:213
#3  sljit_generate_code (compiler=compiler@entry=0x559c95857ef0) at sljit/sljitNativeX86_common.c:506
#4  0x00007f1db668ce9a in _pcre_jit_compile (re=re@entry=0x559c95857d30, extra=extra@entry=0x559c95857da0, 
    mode=mode@entry=0) at pcre_jit_compile.c:11522
#5  0x00007f1db6690742 in pcre_study (external_re=0x559c95857d30, options=options@entry=1, 
    errorptr=errorptr@entry=0x7ffdd9551168) at pcre_study.c:1630
#6  0x0000559c945fdb9d in Pcompile (pattern=0x559c958577a0 "^BOOT_IMAGE=(\\S+)", size=<optimized out>, 
    ignored=<optimized out>) at pcresearch.c:161
#7  0x0000559c945f6bc5 in main (argc=6, argv=0x7ffdd9551938) at grep.c:2884
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

IMHO when "deny_execmem" is enabled, mmap AVCs, which are expected, should be hidden.
It's then up to the caller to take appropriate action (here libpcre doesn't fail but uses another way, from my understanding).

Since troubleshooting may be more difficult due to hiding the AVC, having a boolean to unhide those may be a good option, something like "dontaudit_mmap" or similar.
It should be "on" by default.

Version-Release number of selected component (if applicable):

grep-3.1-6.el8.x86_64
selinux-policy-3.14.3-108.el8.noarch
pcre-8.42-6.el8.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Enable "deny_execmem" boolean

  # semanage boolean -m --on deny_execmem

2. Execute "grep -P" command

  # grep -P -o '^BOOT_IMAGE=(\S+)' /proc/cmdline

Actual results:

AVC but grep functional

Expected results:

No AVC

Additional info:

"grep -P" is used in kexec-tools-2.0.24-6.el8 but can be used in any other script.
Comment 1 Renaud Métrich 2022-11-15 09:58:41 UTC 
Adding PCRE maintainers as well since they should be aware of the issue.
Comment 2 Petr Pisar 2022-11-15 11:02:47 UTC 
The assessment is correct. If an application (grep) requests a JIT compilation, PCRE tries to mmap() the memory, it fails and falls back to an interpreted regexp matching. A collateral damage is the AVC warning. A general approach is patching SELinux policy for the given application to hide the warning. A disadvantage is one need to do this for each SELinux domain. One could hide the warnings globally, but that would hide all breach attempts utilizing this attack vector.

Theoretically, PCRE library could be enhanced to check the deny_execmem SELinux boolean before calling mmap(). That would prevent from logging the warning at one place. However, I'm not sure it's the best (security, performance) approach. Can SELinux maintainers comment on it? It's also necessary to highlight that PCRE library is in no-new-features maintenance mode. If this approach proved fruitful, it would aim PCRE2 library (which is not used by RHEL 8 grep).
Comment 3 Petr Lautrbach 2022-11-25 09:33:29 UTC 
(In reply to Petr Pisar from comment #2)
> Theoretically, PCRE library could be enhanced to check the deny_execmem
> SELinux boolean before calling mmap(). That would prevent from logging the
> warning at one place. However, I'm not sure it's the best (security,
> performance) approach. Can SELinux maintainers comment on it? It's also
> necessary to highlight that PCRE library is in no-new-features maintenance
> mode. If this approach proved fruitful, it would aim PCRE2 library (which is
> not used by RHEL 8 grep).

It might be a solution just for RHEL selinux-policy where `deny_execmem` boolean is defined. A general SELinux policy doesn't necessarily define that and it's not even defined in refpolicy - the original upstream for RHEL policy.
Comment 4 Petr Lautrbach 2022-11-25 09:40:27 UTC 
From my POV, it seems to be something what could be only solved by a user. If they enable `deny_execmen` they most likely want to know when this happens and if it's something expected, as in this particular case, they could add their own 'dontaudit' local policy.
Comment 5 Renaud Métrich 2023-01-16 08:45:24 UTC 
I understand nothing can be done on the PCRE library for now, also, if a user enables `deny_execmem`, he has to deal with AVCs that will pop up.

Unfortunately the solution with adding dontaudit rules is not that simple, because the user just cannot know if the AVC is legit or not, since the granularity of AVCs is on SELinux types only and it's not possible to specify to which executable it should apply.
Hence to enhance the granularity, the user would have to create a specific type for *grep* (e.g. `grep_exec_t`), then add some transition which would then allow allowing execmem for grep only, whatever the caller context is.
Comment 6 Zdenek Pytela 2023-02-02 16:42:35 UTC 
I reviewed this bz and haven't managed to find any other solution or a different approach towards resolving the reported issue.
I deny_execmem is enabled, the related permissions are denied and audited. I think this is the correct and expected behaviour. It is then up to the administrator to assess the denials and decide upon further actions.

If no other concern appears here, I will close the bz.

FYI refpolicy has:
gen_tunable(allow_execmem,false)
Comment 7 Renaud Métrich 2023-02-20 14:15:10 UTC 
I disagree with this: it's not possible for the administrator to analyze such denies and whitelist those based on some rule (e.g. "execution of grep is allowed") because the program can potentially run in any context since "grep" doesn't execute in its own context.
Comment 10 Zdenek Pytela 2023-07-25 19:32:58 UTC 
As no new information appeared during the past weeks, we are going to close this bug. If you need to pursue this matter forward, feel free to reopen this bug and attach the information needed for further assessing.
Comment 14 RHEL Program Management 2023-09-02 00:59:12 UTC 
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.
Comment 15 RHEL Program Management 2023-09-02 01:00:05 UTC 
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.
Note You need to log in before you can comment on or make changes to this bug.