Deciphering an SELinux warning

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.

From Dan Walsh’s Blog – Confining the unconfined. Oxymoron?:

The only confined applications that have the mmap_zero privilege in RHEL5 are vbetool, xdm, xserver and wine.

See also: mmap_min_addr and your local LSM (ok, just SELinux) [LWN.net]

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.

# dontaudit spc_t self:memprotect mmap_zero
3 Likes

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}

In the check_packages() function, I see calls to functions like R_check_unsafe_calls().

Excerpted from r-internals/tools.html:

R_CHECK_UNSAFE_CALLS

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.

2 Likes

Yeah, good call check with dnf provides. I do have R installed. However, I wasn’t doing anything R-related when I got this alert.

For now, I’ll uninstall R just to narrow down suspects and see if I run into the alert again.

1 Like

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.

I’ve removed R and still got the alert. Happens when at boot up (or first login?). The search continues.

1 Like

You can find the binary using the context from the SELinux alert message.

1 Like

I’m not sure I understand. If I do sudo find / -context 'system_u:system_r:spc_t:s0', I get nothing.

1 Like

Be sure to check the date of that warning message, otherwise it may no longer be relevant due to missing files or changed labels.

1 Like

same problem here on my fedora 37

1 Like

If you say you have the same problem, please post the exact message so we can see and interpret its meaning.

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
1 Like

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.

1 Like

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
1 Like