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 2112228 - AVC denials causing redis service failure with mailx core dump
Summary: AVC denials causing redis service failure with mailx core dump
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.7
Hardware: Unspecified
OS: Linux
medium
high
Target Milestone: rc
: 8.8
Assignee: Zdenek Pytela
QA Contact: Amith
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-29 06:27 UTC by Amith
Modified: 2023-05-16 11:01 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-3.14.3-115.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-16 09:03:44 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1503 0 None open Allow redis get user names 2022-12-09 14:47:48 UTC
Red Hat Issue Tracker RHELPLAN-129601 0 None None None 2022-07-29 06:50:23 UTC
Red Hat Product Errata RHBA-2023:2965 0 None None None 2023-05-16 09:04:03 UTC

Comment 1 Zdenek Pytela 2022-11-11 12:50:58 UTC 
I believe this is not a bug: the rules are already in the policy, but the redis_enable_notify tunable, which is off by default, needs to be turned on:


optional_policy(`
	tunable_policy(`redis_enable_notify',`
		auth_read_passwd_file(redis_t)
	')
')
Comment 2 Amith 2022-12-07 12:44:00 UTC 
(In reply to Zdenek Pytela from comment #1)
> I believe this is not a bug: the rules are already in the policy, but the
> redis_enable_notify tunable, which is off by default, needs to be turned on:
> 
> 
> optional_policy(`
> 	tunable_policy(`redis_enable_notify',`
> 		auth_read_passwd_file(redis_t)
> 	')
> ')

Recently bumped into this bug again while executing the test suite against RHEL-8.8.0-20221206.0 and found the AVC. The redis_enable_notify is ON during the execution of test case. Please refer the test result below where you can see "Command 'setsebool redis_enable_notify on' (Expected 0, got 0)".

Is there any other reason for this AVC, or should we do more investigation in the issue ?

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   real scenario -- standalone service
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 07:37:42 ] :: [   PASS   ] :: Command 'echo redhat | passwd --stdin root' (Expected 0, got 0)
:: [ 07:37:43 ] :: [   PASS   ] :: Command 'service redis start' (Expected 0, got 0)
:: [ 07:37:46 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis-server"' (Expected 0, got 0)
:: [ 07:37:46 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis_t.*redis-server"' (Expected 0, got 0)
:: [ 07:37:47 ] :: [   PASS   ] :: Command 'service redis status' (Expected 0,1,3, got 0)
:: [ 07:37:50 ] :: [   PASS   ] :: Command 'service redis restart' (Expected 0, got 0)
:: [ 07:37:53 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis-server"' (Expected 0, got 0)
:: [ 07:37:53 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis_t.*redis-server"' (Expected 0, got 0)
:: [ 07:37:54 ] :: [   PASS   ] :: Command 'service redis status' (Expected 0,1,3, got 0)
:: [ 07:37:57 ] :: [   PASS   ] :: Command 'service redis stop' (Expected 0, got 0)
:: [ 07:37:59 ] :: [   PASS   ] :: Command 'service redis status' (Expected 0,1,3, got 3)
:: [ 07:38:02 ] :: [   PASS   ] :: Command 'cp -f notify.sh /var/lib/redis' (Expected 0, got 0)
:: [ 07:38:02 ] :: [   PASS   ] :: Command 'chmod a+x /var/lib/redis/notify.sh' (Expected 0, got 0)
:: [ 07:38:02 ] :: [   PASS   ] :: Command 'chcon -t bin_t /var/lib/redis/notify.sh' (Expected 0, got 0)
:: [ 07:38:02 ] :: [   PASS   ] :: Command 'chown redis:redis /var/lib/redis/notify.sh' (Expected 0, got 0)
:: [ 07:38:02 ] :: [   PASS   ] :: Command 'sed -i 's/^.*sentinel.*notification-script.*$//' /etc/redis-sentinel.conf' (Expected 0, got 0)
:: [ 07:38:02 ] :: [   PASS   ] :: Command 'echo sentinel notification-script mymaster /var/lib/redis/notify.sh >> /etc/redis-sentinel.conf' (Expected 0, got 0)
:: [ 07:38:03 ] :: [   PASS   ] :: Command 'service postfix start' (Expected 0, got 0)
:: [ 07:38:05 ] :: [   LOG    ] :: the /var/spool/mail/root file does not exist yet
:: [ 07:38:05 ] :: [   PASS   ] :: Command 'touch before-notify.txt' (Expected 0, got 0)
:: [ 07:38:05 ] :: [   PASS   ] :: Command 'setsebool redis_enable_notify on' (Expected 0, got 0)
:: [ 07:38:05 ] :: [   PASS   ] :: Command 'service redis-sentinel start' (Expected 0, got 0)
:: [ 07:38:08 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis-sentinel"' (Expected 0, got 0)
:: [ 07:38:08 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis_t.*redis-sentinel"' (Expected 0, got 0)
:: [ 07:38:09 ] :: [   PASS   ] :: Command 'service redis-sentinel status' (Expected 0,1,3, got 0)
:: [ 07:38:12 ] :: [   PASS   ] :: Command 'service redis-sentinel restart' (Expected 0, got 0)
:: [ 07:38:15 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis-sentinel"' (Expected 0, got 0)
:: [ 07:38:15 ] :: [   PASS   ] :: Command 'ps -efZ | grep -v " grep " | grep -E "redis_t.*redis-sentinel"' (Expected 0, got 0)
:: [ 07:38:16 ] :: [   PASS   ] :: Command 'service redis-sentinel status' (Expected 0,1,3, got 0)
:: [ 07:38:19 ] :: [   PASS   ] :: Command 'service redis-sentinel stop' (Expected 0, got 0)
:: [ 07:38:22 ] :: [   PASS   ] :: Command 'service redis-sentinel status' (Expected 0,1,3, got 3)
:: [ 07:38:29 ] :: [   PASS   ] :: Command 'setsebool redis_enable_notify off' (Expected 0, got 0)
:: [ 07:38:29 ] :: [   FAIL   ] :: Command 'cat /var/spool/mail/root > after-notify.txt' (Expected 0, got 1)
:: [ 07:38:29 ] :: [   FAIL   ] :: Command 'diff before-notify.txt after-notify.txt | grep -i 'subject.*notification-script-test'' (Expected 0, got 1)
:: [ 07:38:29 ] :: [   FAIL   ] :: Command 'diff before-notify.txt after-notify.txt | grep -i selinux' (Expected 0, got 1)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 47s
::   Assertions: 31 good, 3 bad
::   RESULT: FAIL (real scenario -- standalone service)
Comment 3 Milos Malik 2022-12-07 14:53:49 UTC 
During the investigation of test results provided by Amith:
 * http://pastebin.test.redhat.com/1084300

I realized that the problem is NOT in the read operation of file labeled passwd_file_t, because it is allowed:

# rpm -qa selinux\*
selinux-policy-38.1.2-1.el9.noarch
selinux-policy-targeted-38.1.2-1.el9.noarch
selinux-policy-devel-38.1.2-1.el9.noarch
# sesearch -s redis_t -t passwd_file_t -c file -p read -A
allow redis_t passwd_file_t:file { getattr ioctl lock open read }; [ redis_enable_notify ]:True
#

The problem is in the write operation into socket labeled sssd_var_lib_t which is not allowed:

# rpm -qa selinux\*
selinux-policy-38.1.2-1.el9.noarch
selinux-policy-targeted-38.1.2-1.el9.noarch
selinux-policy-devel-38.1.2-1.el9.noarch
# sesearch -s redis_t -t sssd_var_lib_t -c sock_file -p write -A
# sesearch -s redis_t -t sssd_var_lib_t -c sock_file -p write -A --dontaudit
#

Why would the mailx program write into the /var/lib/sss/pipes/nss socket?

Did the mailx program (please notice the "s-nail-14.9.23/src/su/mem-tools.c" messages) dump its core because it could not write into /var/lib/sss/pipes/nss socket.
Or was it the other way round?
Comment 4 Zdenek Pytela 2022-12-09 13:59:30 UTC 
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd[1]: Starting Redis Sentinel...
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd[1]: Started Redis Sentinel.
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 redis-sentinel[20456]: s-nail: Panic: Cannot associate a name with uid 994
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 redis-sentinel[20456]: Crash NYD listing written to /tmp/s-nail.dat
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd[1]: Started Process Core Dump (PID 20457/UID 0).
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd-coredump[20473]: Resource limits disable core dumping for process 20456 (mailx).
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd-coredump[20473]: Process 20456 (mailx) of user 994 dumped core.
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 redis-sentinel[20454]: /var/lib/redis/notify.sh: line 3: 20455 Done                    sestatus
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 redis-sentinel[20454]:     20456 Aborted                 (core dumped) | mailx -s notification-script-test root@localhost
Dec  9 06:38:37 zpytela-1mt-rhel-8-8-0-20221206-0-241078-2022-12-09-11-32 systemd[1]: systemd-coredump: Succeeded.

IMHO s-nail crashes because it cannot get passwd entry for uid 994 (redis).
Also note mailx does not work either, but does not crash; unlike s-nail, mailx is in rhel repo. I suggest we change /usr/bin/mailx dependency to mailx directly.

However, I found out this commit has not been backported to RHEL 8 yet so I was incorrect in #c1.

commit 51f6e947fe84042a2e149669baa91335fa713149
Author: Zdenek Pytela <zpytela>
Date:   Wed Oct 27 18:15:40 2021 +0200

    Allow redis-sentinel execute a notification script

    The following permissions were added contionally when
    the redis_enable_notify boolean is turned on:
    - get the attributes of tmpfs directories
    - read the passwords file
    - connect to systemd-userdbd with a unix socket

It needs to be updated anyway because sssd_stream_connect(redis_t) is also needed, we'll probably replace auth_read_passwd_file() with auth_read_passwd().
Comment 5 Zdenek Pytela 2022-12-14 15:12:44 UTC 
To backport:
commit 24874ee0abb087a9948f43b865fabddeef819cd6 (HEAD -> rawhide, upstream/rawhide)
Author: Zdenek Pytela <zpytela>
Date:   Fri Dec 9 15:44:10 2022 +0100

    Allow redis get user names
Comment 30 errata-xmlrpc 2023-05-16 09:03:44 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2965
Note You need to log in before you can comment on or make changes to this bug.