Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1698197

Summary: selinux blocks systemd during coredump processing
Product: Red Hat Enterprise Linux 8 Reporter: Eric Sandeen <esandeen>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: low Docs Contact:
Priority: low    
Version: 8.0CC: lvrabec, mmalik, plautrba, ssekidde, yoyang, zpytela
Target Milestone: rcKeywords: Patch
Target Release: 8.2Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:40:35 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 Eric Sandeen 2019-04-09 19:25:32 UTC
It's not entirely clear to me what's going on here, but it's easy enough to reproduce.

When I run xfstests generic/394, which attempts to exceed a size limit:

# set max file size to 1G (in block number of 1k blocks), so it should be big
# enough to let test run without bringing any trouble to test harness
ulimit -f $((1024 * 1024))
# default action to SIGXFSZ is coredump, limit core file size to 0 to avoid
# such core files after each test run
# ulimit -c 0

# exercise file size limit boundaries
do_truncate $((1024 * 1024 * 1024 - 1)) $TEST_DIR/$seq.$$-1
do_truncate $((1024 * 1024 * 1024))     $TEST_DIR/$seq.$$
do_truncate $((1024 * 1024 * 1024 + 1)) $TEST_DIR/$seq.$$+1 2>&1 | \
        grep -o "File size limit exceeded"


it triggers an AVC:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31
selinux-policy-3.14.1-61.el8.noarch
----
time->Tue Apr  9 00:25:03 2019
type=PROCTITLE msg=audit(1554783903.443:2761): proctitle="(coredump)"
type=SYSCALL msg=audit(1554783903.443:2761): arch=c000003e syscall=165 success=no exit=-13 a0=0 a1=5568c0235ec0 a2=0 a3=1021 items=0 ppid=1 pid=25285 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(coredump)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(1554783903.443:2761): avc:  denied  { remount } for  pid=25285 comm="(coredump)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=filesystem permissive=0


stracing systemd (which handles coredump, I guess?) I see:

mount(NULL, "/run/systemd/unit-root/mnt/scratch", NULL, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EACCES (Permission denied)

The filesystem under test has been moungted with an fs-wide context,

MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/loop1 /mnt/scratch

so I guess that's a mismatch vs. system_u:system_r:init_t:s0 

I don't know for sure if this should be rejected or not, but figured I'd flag it.

more from debugging:

Apr 09 15:23:51 dell-per620-01.khw.lab.eng.bos.redhat.com setroubleshoot[26818]: SELinux is preventing  /usr/lib/systemd/systemd from remount access on the filesystem . For complete SELinux messages run: sealert -l aca0af85-8bd9-4038-9889-37acacfdb197


# sealert -l aca0af85-8bd9-4038-9889-37acacfdb197
SELinux is preventing /usr/lib/systemd/systemd from remount access on the filesystem .

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that systemd should be allowed remount access on the  filesystem 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 '(coredump)' --raw | audit2allow -M my-coredump
# semodule -X 300 -i my-coredump.pp


Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:root_t:s0
Target Objects                 [ filesystem ]
Source                        (coredump)
Source Path                   /usr/lib/systemd/systemd
Port                          <Unknown>
Host                          dell-per620-01.khw.lab.eng.bos.redhat.com
Source RPM Packages           systemd-239-13.el8.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.1-61.el8.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     dell-per620-01.khw.lab.eng.bos.redhat.com
Platform                      Linux dell-per620-01.khw.lab.eng.bos.redhat.com
                              4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46
                              UTC 2019 x86_64 x86_64
Alert Count                   1
First Seen                    2019-04-09 15:23:47 EDT
Last Seen                     2019-04-09 15:23:47 EDT
Local ID                      aca0af85-8bd9-4038-9889-37acacfdb197

Raw Audit Messages
type=AVC msg=audit(1554837827.401:431): avc:  denied  { remount } for  pid=26503 comm="(coredump)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=filesystem permissive=0


type=SYSCALL msg=audit(1554837827.401:431): arch=x86_64 syscall=mount success=no exit=EACCES a0=0 a1=55656ac733e0 a2=0 a3=1021 items=0 ppid=1 pid=26503 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=(coredump) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null)

Hash: (coredump),init_t,root_t,filesystem,remount

Comment 6 Milos Malik 2019-12-01 20:16:27 UTC
Please re-run your scenario with the latest selinux-policy packages installed and let us know if the provided fix is sufficient.

Thank you.

Comment 7 Eric Sandeen 2019-12-11 16:13:02 UTC
Hm, I tested with:

# rpm -q selinux-policy
selinux-policy-3.14.3-20.el8.noarch
# sesearch -s init_t -t root_t -c filesystem -p remount -A
#

and the testcase succeeds as expected, not sure what to make of that, as I'm not sure I have the fix, and yet it seems to work now:

# ./check  generic/394
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 fs-i40c-06 4.18.0-163.el8.x86_64 #1 SMP Tue Dec 10 21:20:06 UTC 2019
MKFS_OPTIONS  -- -f -bsize=4096 /dev/loop1
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/loop1 /mnt/scratch

generic/394 1s ...  2s
Ran: generic/394
Passed all 1 tests
#

Comment 10 errata-xmlrpc 2020-04-28 16:40:35 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, 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-2020:1773