Bug 1253319 - SELinux prevents systemd-coredump from working
Summary: SELinux prevents systemd-coredump from working
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 22
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1285894 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-13 13:25 UTC by Stef Walter
Modified: 2016-05-10 17:56 UTC (History)
10 users (show)

Fixed In Version: seselinux-policy-3.13.1-128.26.fc22 selinux-policy-3.13.1-128.28.fc22
Clone Of:
Environment:
Last Closed: 2016-05-10 17:56:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stef Walter 2015-08-13 13:25:02 UTC
Description of problem:

Aug 13 09:19:22 m10 audit[226]: <audit-1400> avc:  denied  { read write } for  pid=226 comm="systemd-journal" path=2F6D656D66643A73642D73797374656D642D636F726564756D202864656C6574656429 dev="tmpfs" ino=23115 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0


The following fixes the issue:

#============= syslogd_t ==============
allow syslogd_t tmpfs_t:file { read write };


Version-Release number of selected component (if applicable):

selinux-policy-targeted-3.13.1-128.8.fc22.noarch

How reproducible:

Every time

Steps to Reproduce:
1. echo "kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e" > /etc/sysctl.d/50-coredump.conf
2. printf "[Coredump]\nStorage=journal\n" > /etc/systemd/coredump.conf
3. reboot
4. crash a process

Actual results:

[root@m10 ~]# coredumpctl
No coredumps found.

Expected results:

[root@m10 ~]# setenforce 0
[root@m10 ~]# cockpit-bridge # crashing a process here
Segmentation fault (core dumped)
[root@m10 ~]# coredumpctl
TIME                            PID   UID   GID SIG PRESENT EXE
Do 2015-08-13 09:23:14 EDT     1060     0     0  11   /usr/bin/cockpit-bridge

Comment 1 Stef Walter 2015-08-13 13:27:07 UTC
There's more:

Aug 13 09:19:22 m10 audit[226]: <audit-1400> avc:  denied  { read write } for  pid=226 comm="systemd-journal" path=2F6D656D66643A73642D73797374656D642D636F726564756D202864656C6574656429 dev="tmpfs" ino=23115 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0 
Aug 13 09:25:09 m10 audit[226]: <audit-1400> avc:  denied  { getattr } for  pid=226 comm="systemd-journal" path=2F6D656D66643A73642D73797374656D642D636F726564756D202864656C6574656429 dev="tmpfs" ino=23784 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0

Comment 2 Daniel Walsh 2015-08-13 14:23:36 UTC
Looks like systemd-journal is using some tmpfs file system probably in /dev/shm.  Wierd that it did not use an Open.  I think this might be a kernel issue, which is being worked on upstream where file descriptors are being checked without file ever being created.

We should just allow it until the kernel is fixed.

Comment 3 Daniel Walsh 2015-08-13 14:25:01 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1013878 discusses this

Comment 4 Daniel Walsh 2015-08-13 14:28:14 UTC
I guess we need to have a transition rule added for syslogd_t to create a tmpfs_t, file.  

I thought I saw some movement on this in the kernel recently, but I guess I was wrong from reading the above bug report.

Comment 5 Paul Moore 2015-08-13 15:06:27 UTC
There have been some patches recently to stop the SELinux bits in the kernel for checking shmem segments backed against tmpfs and/or hugetlbfs.  The patches were originally to fix some locking problems in xfs, but I believe they will apply here too if I'm understanding this BZ correctly.

I'm fairly certain that the patch was picked up for v4.2.

 * https://marc.info/?l=selinux&m=143766964815030&w=2

Comment 6 Miroslav Grepl 2015-08-15 10:51:15 UTC
(In reply to Daniel Walsh from comment #4)
> I guess we need to have a transition rule added for syslogd_t to create a
> tmpfs_t, file.  

Yes, we need to add a transition.


> 
> I thought I saw some movement on this in the kernel recently, but I guess I
> was wrong from reading the above bug report.

Comment 7 Stef Walter 2015-09-26 08:04:47 UTC
Here is another case of SELinux preventing coredumps from working. If this is not related, let me know and I can open another bug.

Sep 25 22:23:06 m14 kernel: audit: type=1400 audit(1443219785.175:644): avc:  denied  { read write } for  pid=220 comm="systemd-journal" path=2F6D656D66643A73642D73797374656D642D636F726564756D202864656C6574656429 dev="tmpfs" ino=24889 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0

The path is hex encoded and decodes to:

/memfd:sd-systemd-coredum (deleted)

This was seen multiple times during Cockpit integration tests.

Comment 8 Wilf 2015-11-26 22:11:12 UTC
I'm not sure if this is relevant:

https://bugzilla.redhat.com/show_bug.cgi?id=1285894

Comment 9 Stef Walter 2015-11-27 08:03:45 UTC
Bug #1285894 seems like a duplicate, no?

Comment 10 Stef Walter 2015-12-17 06:59:25 UTC
This continues to happens every so often in the Cockpit integration tests, which we run with SELinux enforcing, and fail if we get any audit: type=14XX

Here's another example:

http://files.cockpit-project.org/logs/pull-3342-d9192cd5-fedora-23/TestStorage-testRaid-10.111.127.109-FAIL.log

Dec 16 19:39:05 localhost.localdomain systemd-udevd[1513]: Assertion 'subsystem' failed at src/libsystemd/sd-device/sd-device.c:1194, function device_get_id_filename(). Aborting.
Dec 16 19:39:05 localhost.localdomain audit[1513]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:udev_t:s0-s0:c0.c1023 pid=1513 comm="systemd-udevd" exe="/usr/lib/systemd/systemd-udevd" sig=6
Dec 16 19:39:05 localhost.localdomain systemd-udevd[331]: worker [1513] terminated by signal 6 (Aborted)
Dec 16 19:39:05 localhost.localdomain systemd-udevd[331]: worker [1513] failed while handling '/devices/virtual/block/md127/md127p2'
Dec 16 19:39:05 localhost.localdomain storaged[1021]: No longer watching mdraid device 9:127
Dec 16 19:39:05 localhost.localdomain systemd-udevd[1514]: inotify_add_watch(9, /dev/md127p2, 10) failed: No such file or directory
Dec 16 19:39:05 localhost.localdomain kernel: audit: type=1400 audit(1450294745.160:654): avc:  denied  { read write } for  pid=296 comm="systemd-journal" path=2F6D656D66643A73642D73797374656D642D636F726564756D202864656C6574656429 dev="tmpfs" ino=26052 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0
Dec 16 19:39:05 localhost.localdomain kernel: audit: type=1300 audit(1450294745.160:654): arch=c000003e syscall=47 success=yes exit=0 a0=5 a1=7ffc8c945600 a2=40000040 a3=ffffffff items=0 ppid=1 pid=296 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-journal" exe="/usr/lib/systemd/systemd-journald" subj=system_u:system_r:syslogd_t:s0 key=(null)
Dec 16 19:39:05 localhost.localdomain kernel: audit: type=1327 audit(1450294745.160:654): proctitle="/usr/lib/systemd/systemd-journald"
Dec 16 19:39:05 localhost.localdomain audit[296]: AVC avc:  denied  { read write } for  pid=296 comm="systemd-journal" path=2F6D656D66643A73642D73797374656D642D636F726564756D202864656C6574656429 dev="tmpfs" ino=26052 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0

Comment 11 Stef Walter 2015-12-17 22:08:42 UTC
We're starting to put in ugly workarounds for this:

https://github.com/cockpit-project/cockpit/pull/3352

Comment 12 Stef Walter 2016-01-05 12:43:20 UTC
This continues to happen. SELinux breaks system core dumps. More work arounds:

https://github.com/cockpit-project/cockpit/pull/3420

Comment 14 Lukas Vrabec 2016-01-11 13:09:52 UTC
*** Bug 1285894 has been marked as a duplicate of this bug. ***

Comment 15 Lukas Vrabec 2016-01-12 00:50:07 UTC
Guys, 
After some research, I found solution for this issue. The problem is that we don't have policy for systemd-coredump helper.

So I'll create basic policy for systemd-coredump and label proper binaries like systemd_coredump_exec_t. After that I'll add domain transition from kernel_t to systemd_coredump_t, because "/usr/lib/systemd/systemd-coredump" is started by kernel, this will quarantee proper label(systemd_coredump_t) for systemd-coredump process. Then I'll add transition rule that systemd_coredump_t will create systemd_coredump_tmpfs_t file in tmpfs_t directory. After that, I can allow syslogd to read/write systemd_coredump_tmpfs_t.

Mirek, 
Do you agree with label name "systemd_coredump_tmpfs_t"? 

I'm going to attach fixes and scratch builds for testing in couple of hours.

Comment 16 Miroslav Grepl 2016-01-12 05:55:58 UTC
(In reply to Lukas Vrabec from comment #15)
> Guys, 
> After some research, I found solution for this issue. The problem is that we
> don't have policy for systemd-coredump helper.
> 
> So I'll create basic policy for systemd-coredump and label proper binaries
> like systemd_coredump_exec_t. After that I'll add domain transition from
> kernel_t to systemd_coredump_t, because "/usr/lib/systemd/systemd-coredump"
> is started by kernel, this will quarantee proper label(systemd_coredump_t)
> for systemd-coredump process. Then I'll add transition rule that
> systemd_coredump_t will create systemd_coredump_tmpfs_t file in tmpfs_t
> directory. After that, I can allow syslogd to read/write
> systemd_coredump_tmpfs_t.
> 
> Mirek, 
> Do you agree with label name "systemd_coredump_tmpfs_t"? 
> 
> I'm going to attach fixes and scratch builds for testing in couple of hours.

Ok.

Comment 17 Lukas Vrabec 2016-01-12 13:23:46 UTC
I'm attaching copr repo with last changes.

F24,F23: https://copr.fedoraproject.org/coprs/lvrabec/selinux-policy/ 
F22: https://lvrabec.fedorapeople.org/selinux-policy-3.13.1-128.24.fc22.1.tar.gz

Please, let me know, if it's working.

Comment 18 Miroslav Grepl 2016-01-21 13:56:21 UTC
Will it go as a regular update?

Comment 19 Lukas Vrabec 2016-01-21 14:07:33 UTC
It's just in rawhide package, now. I can backport this, but I would like to get some feedback about testing systemd-coredump policy, due to backporting to stable fedora releases.

Comment 20 Lukas Vrabec 2016-02-04 15:36:51 UTC
commit 0d626964b025a2643915fae39f59731b1c3e2e93
Author: Lukas Vrabec <lvrabec>
Date:   Tue Jan 12 11:45:12 2016 +0100

    Added policy for systemd-coredump service.
    Added domain transition from kernel_t to systemd_coredump_t.
    Allow syslogd_t domain to read/write tmpfs systemd-coredump files.
    Make new domain uconfined for now.

Comment 21 Fedora Update System 2016-02-15 17:46:06 UTC
selinux-policy-3.13.1-128.27.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab

Comment 22 Fedora Update System 2016-02-17 06:25:35 UTC
selinux-policy-3.13.1-128.27.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab

Comment 23 Fedora Update System 2016-02-18 12:26:31 UTC
selinux-policy-3.13.1-128.28.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab

Comment 24 Fedora Update System 2016-02-21 18:28:35 UTC
selinux-policy-3.13.1-128.28.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ce419c9cab

Comment 25 Fedora Update System 2016-05-10 17:55:18 UTC
selinux-policy-3.13.1-128.28.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.