Bug 1838163

Summary: SELinux prevents systemd-journald from recvmsg()-ing the /memfd:sd-systemd-bootcha file
Product: [Fedora] Fedora Reporter: Milos Malik <mmalik>
Component: selinux-policyAssignee: Richard Fiľo <rfilo>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 32CC: dwalsh, grepl.miroslav, lvrabec, plautrba, rfilo, vmojzis, zpytela
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.14.5-43.fc32 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-31 15:50:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Milos Malik 2020-05-20 14:51:31 UTC
Description of problem:

Version-Release number of selected component (if applicable):
selinux-policy-devel-3.14.5-38.fc32.noarch
selinux-policy-targeted-3.14.5-38.fc32.noarch
selinux-policy-3.14.5-38.fc32.noarch
selinux-policy-doc-3.14.5-38.fc32.noarch
systemd-udev-245.4-1.fc32.x86_64
systemd-245.4-1.fc32.x86_64
systemd-journal-remote-245.4-1.fc32.x86_64
systemd-bootchart-233-6.fc32.x86_64
systemd-container-245.4-1.fc32.x86_64
systemd-pam-245.4-1.fc32.x86_64
systemd-rpm-macros-245.4-1.fc32.noarch
systemd-libs-245.4-1.fc32.x86_64

How reproducible:
 * during each reboot

Steps to Reproduce:
1. get a Fedora 31 or 32 machine (targeted policy is active)
2. enable and start the systemd-journald service
3. enable and start the systemd-bootchart service
4. reboot the machine
5. search for SELinux denials after the machine boots up

Actual results:
----
type=PROCTITLE msg=audit(05/20/2020 16:34:18.083:291) : proctitle=/usr/lib/systemd/systemd-journald 
type=SYSCALL msg=audit(05/20/2020 16:34:18.083:291) : arch=x86_64 syscall=recvmsg success=yes exit=0 a0=0x5 a1=0x7ffe8ae16140 a2=MSG_DONTWAIT|MSG_CMSG_CLOEXEC a3=0x0 items=0 ppid=1 pid=536 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) 
type=AVC msg=audit(05/20/2020 16:34:18.083:291) : avc:  denied  { read write } for  pid=536 comm=systemd-journal path=/memfd:sd-systemd-bootcha (deleted) dev="tmpfs" ino=57608 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:systemd_bootchart_tmpfs_t:s0 tclass=file permissive=0 
----

Expected results:
 * no SELinux denials (either the access is allowed or dontaudit-ed)

Additional information:
 * both systemd-* services run successfully even if the SELinux denial appears

Comment 1 Milos Malik 2020-05-20 15:50:00 UTC
The same reproducer triggers the same denial on Fedora Rawhide too:
----
type=PROCTITLE msg=audit(05/20/2020 11:47:25.445:129) : proctitle=/usr/lib/systemd/systemd-journald 
type=SYSCALL msg=audit(05/20/2020 11:47:25.445:129) : arch=x86_64 syscall=recvmsg success=yes exit=0 a0=0x5 a1=0x7ffdba596d80 a2=MSG_DONTWAIT|MSG_CMSG_CLOEXEC a3=0xffffffff items=0 ppid=1 pid=388 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) 
type=AVC msg=audit(05/20/2020 11:47:25.445:129) : avc:  denied  { read write } for  pid=388 comm=systemd-journal path=/memfd:sd-systemd-bootcha (deleted) dev="tmpfs" ino=24407 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:systemd_bootchart_tmpfs_t:s0 tclass=file permissive=0 
----

# rpm -qa selinux\* systemd\* | sort
selinux-policy-3.14.6-9.fc33.noarch
selinux-policy-targeted-3.14.6-9.fc33.noarch
systemd-245.2-1.fc33.x86_64
systemd-bootchart-233-6.fc32.x86_64
systemd-libs-245.2-1.fc33.x86_64
systemd-pam-245.2-1.fc33.x86_64
systemd-rpm-macros-245.2-1.fc33.noarch
systemd-udev-245.2-1.fc33.x86_64
#

Comment 2 Milos Malik 2020-05-20 15:54:16 UTC
Following SELinux denials appeared in permissive mode:
----
type=PROCTITLE msg=audit(05/20/2020 11:53:13.612:159) : proctitle=/usr/lib/systemd/systemd-journald 
type=SYSCALL msg=audit(05/20/2020 11:53:13.612:159) : arch=x86_64 syscall=recvmsg success=yes exit=0 a0=0x4 a1=0x7ffd18060820 a2=MSG_DONTWAIT|MSG_CMSG_CLOEXEC a3=0xffffffff items=0 ppid=1 pid=388 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) 
type=AVC msg=audit(05/20/2020 11:53:13.612:159) : avc:  denied  { read write } for  pid=388 comm=systemd-journal path=/memfd:sd-systemd-bootcha (deleted) dev="tmpfs" ino=25299 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:systemd_bootchart_tmpfs_t:s0 tclass=file permissive=1 
----
type=PROCTITLE msg=audit(05/20/2020 11:53:13.613:160) : proctitle=/usr/lib/systemd/systemd-journald 
type=SYSCALL msg=audit(05/20/2020 11:53:13.613:160) : arch=x86_64 syscall=fstat success=yes exit=0 a0=0x1e a1=0x7ffd18060950 a2=0x7ffd18060950 a3=0x0 items=0 ppid=1 pid=388 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) 
type=AVC msg=audit(05/20/2020 11:53:13.613:160) : avc:  denied  { getattr } for  pid=388 comm=systemd-journal path=/memfd:sd-systemd-bootcha (deleted) dev="tmpfs" ino=25299 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:systemd_bootchart_tmpfs_t:s0 tclass=file permissive=1 
----
type=PROCTITLE msg=audit(05/20/2020 11:53:13.613:161) : proctitle=/usr/lib/systemd/systemd-journald 
type=MMAP msg=audit(05/20/2020 11:53:13.613:161) : fd=30 flags=MAP_PRIVATE 
type=SYSCALL msg=audit(05/20/2020 11:53:13.613:161) : arch=x86_64 syscall=mmap success=yes exit=139818581405696 a0=0x0 a1=0x9e000 a2=PROT_READ a3=MAP_PRIVATE items=0 ppid=1 pid=388 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-journal exe=/usr/lib/systemd/systemd-journald subj=system_u:system_r:syslogd_t:s0 key=(null) 
type=AVC msg=audit(05/20/2020 11:53:13.613:161) : avc:  denied  { map } for  pid=388 comm=systemd-journal path=/memfd:sd-systemd-bootcha (deleted) dev="tmpfs" ino=25299 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:systemd_bootchart_tmpfs_t:s0 tclass=file permissive=1
----

Comment 6 Lukas Vrabec 2020-08-21 14:53:44 UTC
commit 3004ccf1cc412c3c715978b76f2bb549aa12b27a (HEAD -> f32, origin/f32)
Author: Richard Filo <rfilo>
Date:   Thu Aug 20 22:25:28 2020 +0200

    Allow syslogd_t domain to read/write tmpfs systemd-bootchart files
    
    Create the two interfaces to allow mapping and r/w permisions.
    Add this two interfaces to the policy for domain syslogd_t.
    
    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1838163
    
    The one way how can the systemd-journald get a log data from any services is by socket /run/systemd/journal/socket. But when the message is bigger than max size of datagram, it must be done differently. It is by filedescriptor, which is connected to the datagram and in the file to which the file descriptor refers are the log data that were not sent. The file is created by memfd_create() syscall and in kernel the file is implemented as tmpfs.
    
    That means any service can communicate in this way.

Comment 7 Fedora Update System 2020-08-27 21:10:40 UTC
FEDORA-2020-740de661da has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-740de661da

Comment 8 Fedora Update System 2020-08-28 14:55:11 UTC
FEDORA-2020-740de661da has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-740de661da`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-740de661da

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

Comment 9 Fedora Update System 2020-08-31 15:50:04 UTC
FEDORA-2020-740de661da has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.