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.2   
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