I have an SELinux warning SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t. When I google this I don’t find anything obviously the same. How can I determine if this is a serious breach or not? I don’t see how i actually can find out what check is. Full SELinux output below
***** Plugin mmap_zero (53.1 confidence) suggests *************************
If you do not think check should need to mmap low memory in the kernel.
Then you may be under attack by a hacker, this is a very dangerous access.
Do
contact your security administrator and report this issue.
***** Plugin catchall_boolean (42.6 confidence) suggests ******************
If you want to allow mmap to low allowed
Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean.
Do
setsebool -P mmap_low_allowed 1
***** Plugin catchall (5.76 confidence) suggests **************************
If you believe that check should be allowed mmap_zero access on memprotect labeled spc_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 'check' --raw | audit2allow -M my-check
# semodule -X 300 -i my-check.pp
Additional Information:
Source Context system_u:system_r:spc_t:s0
Target Context system_u:system_r:spc_t:s0
Target Objects Unknown [ memprotect ]
Source check
Source Path check
Port <Unknown>
Host fedora
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-36.17-1.fc36.noarch
Local Policy RPM container-selinux-2.199.0-1.fc36.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name fedora
Platform Linux fedora 6.1.10-100.fc36.x86_64 #1 SMP
PREEMPT_DYNAMIC Mon Feb 6 19:58:39 UTC 2023
x86_64 x86_64
Alert Count 60
First Seen 2023-02-14 22:54:15 CET
Last Seen 2023-02-14 22:54:15 CET
Local ID 1ad5dfc6-2b85-422c-9f31-0fee1cf5f868
Raw Audit Messages
type=AVC msg=audit(1676411655.509:366): avc: denied { mmap_zero } for pid=2984 comm="check" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=memprotect permissive=0
Hash: check,spc_t,spc_t,memprotect,mmap_zero
mmap_zero allows access to an area of memory that a hacker could potentially use to gain unlimited access to your system. It looks like spc_t is a label that is mainly used by (docker?) containers. So I guess your question is, “Should I allow my Docker containers access to memory ranges that can be used to exploit the host system?” Unless this selinux error is causing something that you really need not to work, you probably shouldn’t allow that access. That said, there appear to be a handful of programs that do require it to function.
P.S. This comment on a bug report appears to indicate that you could silence these selinux messages (without granting the privilege) by running the following command.
I’ve gotten this exact SELinux alert myself. Weird thing is I don’t have a check command. I think. At least not on my $PATH.
I haven’t been able to track it down but my best guess (if it helps) is something to do with podman-desktop installed as a flatpak, which I’ve installed recently.
I have been using docker on this system for a while now and have never gotten this specific warning before.
This is all I’m seeing with a quick search of the Fedora repositories.
$ dnf provides '*/bin/check'
Last metadata expiration check: 8 days, 16:20:09 ago on Tue 14 Mar 2023 10:34:15 PM CDT.
R-core-4.2.1-5.fc37.i686 : The minimal R components necessary for a functional runtime
Repo : fedora
Matched from:
Filename : /usr/lib/R/bin/check
R-core-4.2.1-5.fc37.x86_64 : The minimal R components necessary for a functional runtime
Repo : fedora
Matched from:
Filename : /usr/lib64/R/bin/check
R-core-4.2.2-1.fc37.i686 : The minimal R components necessary for a functional runtime
Repo : updates
Matched from:
Filename : /usr/lib/R/bin/check
R-core-4.2.2-1.fc37.x86_64 : The minimal R components necessary for a functional runtime
Repo : updates
Matched from:
Filename : /usr/lib64/R/bin/check
And this is the content of that check command.
# rpm -q R-core
R-core-4.1.3-2.fc36.x86_64
$ file /usr/lib64/R/bin/check
/usr/lib64/R/bin/check: ASCII text
$ cat /usr/lib64/R/bin/check
# ${R_HOME}/bin/check -*- sh -*- for checking add-on packages
args=
while test -n "${1}"; do
args="${args}nextArg${1}"
shift
done
## NB: Apple's ICU needs LC_COLLATE set when R is started.
echo 'tools:::.check_packages()' | R_DEFAULT_PACKAGES= LC_COLLATE=C "${R_HOME}/bin/R" --no-restore --no-echo --args ${args}
Check for calls that appear to tamper with (or allow tampering with) already loaded code not from the current package: such calls may well contravene CRAN policies. Default: true.
It may well be that the above or some other pre-flight “test” that R appears to be doing before loading a package is what is setting off SELinux. It also seems likely that such a test is supposed to fail. So granting the permission would be the exact wrong thing to do.
caveat emptor : I don’t know that the above is actually the command that is causing the problem. It is simply the closest match I was able to find with some searching.
It could also be that R (or a program written in R) is installed in one of your flatpaks or containers. I’m not sure if a SELinux warning could bubble up from within such a “sandboxed” environment or not.
FWIW, I get this error when running Fedora Workstation 38 (Gnome), then install CInnamon - dnf groupinstall "Cinnamon Desktop". The error comes up immediately after restarting the workstation. I’ve tried on multiple devices to confirm.
FWIW I do have docker installed, and part of the install for docker engine involves changing SELinux container packages. Possibly related. If folks are interested, I can test a fresh install to confirm whether docker being installed affects the error being returned.
If you do not think check should need to mmap low memory in the kernel.
Then you may be under attack by a hacker, this is a very dangerous access.
Do
contact your security administrator and report this issue.
***** Plugin catchall_boolean (42.6 confidence) suggests ******************
If you want to allow mmap to low allowed
Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean.
Do
setsebool -P mmap_low_allowed 1
***** Plugin catchall (5.76 confidence) suggests **************************
If you believe that check should be allowed mmap_zero access on memprotect labeled spc_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 'check' --raw | audit2allow -M my-check
# semodule -X 300 -i my-check.pp
This should not be a problem since it relates to containers.
One may relabel all files on the system with sudo touch /.autorelabel then a reboot which allows time for selinux to relabel the context for all the files as the system restarts. Doing this should fix the problem with the cinnamon desktop.
The same thing may be done without a reboot by using sudo restorecon -R / but the system then must remain active long enough for the relabel to be verified &/or updated on the entire file system before it is shutdown or suspended.
So is the solution so far to just, ignore this warning? I’m getting the same warning, I also have docker installed, and this system is fresh as of last week (basically just Fedora 38 with a handful of packages installed):
SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t.
***** Plugin mmap_zero (53.1 confidence) suggests *************************
If you do not think check should need to mmap low memory in the kernel.
Then you may be under attack by a hacker, this is a very dangerous access.
Do
contact your security administrator and report this issue.
***** Plugin catchall_boolean (42.6 confidence) suggests ******************
If you want to allow mmap to low allowed
Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean.
Do
setsebool -P mmap_low_allowed 1
***** Plugin catchall (5.76 confidence) suggests **************************
If you believe that check should be allowed mmap_zero access on memprotect labeled spc_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 'check' --raw | audit2allow -M my-check
# semodule -X 300 -i my-check.pp
Additional Information:
Source Context system_u:system_r:spc_t:s0
Target Context system_u:system_r:spc_t:s0
Target Objects Unknown [ memprotect ]
Source check
Source Path check
Port <Unknown>
Host melinoe
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-38.27-1.fc38.noarch
Local Policy RPM container-selinux-2.221.1-1.fc38.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name melinoe
Platform Linux melinoe 6.4.15-200.fc38.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Sep 7 00:25:01 UTC 2023
x86_64
Alert Count 150
First Seen 2023-09-14 14:09:51 EDT
Last Seen 2023-09-14 16:40:02 EDT
Local ID fedef952-265f-41bc-a217-a2cbdaa5c3ac
Raw Audit Messages
type=AVC msg=audit(1694724002.889:1765): avc: denied { mmap_zero } for pid=200222 comm="check" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=memprotect permissive=0
Hash: check,spc_t,spc_t,memprotect,mmap_zero