Bug 2217165 - SELinux is preventing aide from using the 'execmem' accesses on a process.
Summary: SELinux is preventing aide from using the 'execmem' accesses on a process.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 38
Hardware: x86_64
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:d4180c2b606e5f34adfd984aefb...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-24 16:54 UTC by Matt Fagnani
Modified: 2023-09-11 07:57 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-38.20-1.fc38
Clone Of:
Environment:
Last Closed: 2023-07-01 01:46:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: os_info (699 bytes, text/plain)
2023-06-24 16:54 UTC, Matt Fagnani
no flags Details
File: description (2.11 KB, text/plain)
2023-06-24 16:54 UTC, Matt Fagnani
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1767 0 None open Dontaudit aide the execmem permission 2023-06-28 17:02:54 UTC

Description Matt Fagnani 2023-06-24 16:54:04 UTC
Description of problem:
After an update containing aide-0.18.4-2.fc38.x86_64 https://bodhi.fedoraproject.org/updates/FEDORA-2023-ffe6b2a5a0, aide --check was denied execmem 2/2 times when started as a cron job. This cron job was created when I ran a SCAP Workbench remediation script in 2020. This denial didn't happen with aide-0.16-22.fc38.x86_64 or earlier. The denial didn't happen when I ran sudo aide --check in Konsole with aide-0.18.4-2.fc38.x86_64 installed. 
SELinux is preventing aide from using the 'execmem' accesses on a process.

*****  Plugin allow_execmem (91.4 confidence) suggests   *********************

If this issue occurred during normal system operation.
Then this alert could be a serious issue and your system could be compromised.
Do
contact your security administrator and report this issue

*****  Plugin catchall (9.59 confidence) suggests   **************************

If you believe that aide should be allowed execmem access on processes labeled aide_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'aide' --raw | audit2allow -M my-aide
# semodule -X 300 -i my-aide.pp

Additional Information:
Source Context                system_u:system_r:aide_t:s0-s0:c0.c1023
Target Context                system_u:system_r:aide_t:s0-s0:c0.c1023
Target Objects                Unknown [ process ]
Source                        aide
Source Path                   aide
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.17-1.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.17-1.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 6.3.9-200.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Jun 21 19:47:58 UTC 2023
                              x86_64
Alert Count                   2
First Seen                    2023-06-22 04:05:01 EDT
Last Seen                     2023-06-23 04:05:01 EDT
Local ID                      ff0dff65-70b4-4afc-ab39-c2b1bd2e8a4c

Raw Audit Messages
type=AVC msg=audit(1687507501.88:261): avc:  denied  { execmem } for  pid=2828 comm="aide" scontext=system_u:system_r:aide_t:s0-s0:c0.c1023 tcontext=system_u:system_r:aide_t:s0-s0:c0.c1023 tclass=process permissive=0


Hash: aide,aide_t,aide_t,process,execmem

Version-Release number of selected component:
selinux-policy-targeted-38.17-1.fc38.noarch

Additional info:
reporter:       libreport-2.17.10
hashmarkername: setroubleshoot
comment:        After an update containing aide-0.18.4-2.fc38.x86_64 https://bodhi.fedoraproject.org/updates/FEDORA-2023-ffe6b2a5a0, aide --check was denied execmem 2/2 times when started as a cron job. This cron job was created when I ran a SCAP Workbench remediation script in 2020. This denial didn't happen with aide-0.16-22.fc38.x86_64 or earlier. The denial didn't happen when I ran sudo aide --check in Konsole with aide-0.18.4-2.fc38.x86_64 installed. 
type:           libreport
kernel:         6.3.9-200.fc38.x86_64
component:      selinux-policy
package:        selinux-policy-targeted-38.17-1.fc38.noarch
reason:         SELinux is preventing aide from using the 'execmem' accesses on a process.
component:      selinux-policy

Comment 1 Matt Fagnani 2023-06-24 16:54:06 UTC
Created attachment 1972379 [details]
File: os_info

Comment 2 Matt Fagnani 2023-06-24 16:54:07 UTC
Created attachment 1972380 [details]
File: description

Comment 3 Zdenek Pytela 2023-06-26 09:53:06 UTC
Rado,

Is the execmem permission request a result of the aide rebase?
Did you come across it as well?

Comment 4 Matt Fagnani 2023-06-28 00:45:48 UTC
I saw this execmem denial a third time within a second of aide being run from the cron job. aide completed even with the denial. aide-0.18.4-2.fc38 involved porting to pcre2 https://koji.fedoraproject.org/koji/buildinfo?buildID=2218512 https://bugzilla.redhat.com/show_bug.cgi?id=2128267 The use of pcre2 JIT-compiled regular expressions resulted in execmem denials for libvirt https://bugzilla.redhat.com/show_bug.cgi?id=2122918 proftpd https://bugzilla.redhat.com/show_bug.cgi?id=2161705 and tshark https://bugzilla.redhat.com/show_bug.cgi?id=2163800 Those cases appear to have been fixed by using dontaudit for execmem.

Comment 5 Zdenek Pytela 2023-06-28 17:02:54 UTC
Thank you, Matt, I am going to dontaudit it right away; still, I'd like to hear from developers if there is an issue with this approach, e.g. performance penalty.

Comment 6 Fedora Update System 2023-06-29 16:14:52 UTC
FEDORA-2023-ba070ee6ba has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba

Comment 7 Fedora Update System 2023-06-30 01:40:29 UTC
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ba070ee6ba`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2023-07-01 01:46:01 UTC
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.