Hide Forgot
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
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
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1013878 discusses this
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.
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
(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.
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.
I'm not sure if this is relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1285894
Bug #1285894 seems like a duplicate, no?
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
We're starting to put in ugly workarounds for this: https://github.com/cockpit-project/cockpit/pull/3352
This continues to happen. SELinux breaks system core dumps. More work arounds: https://github.com/cockpit-project/cockpit/pull/3420
*** Bug 1285894 has been marked as a duplicate of this bug. ***
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.
(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.
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.
Will it go as a regular update?
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.
commit 0d626964b025a2643915fae39f59731b1c3e2e93 Author: Lukas Vrabec <lvrabec@redhat.com> 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.
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
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
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
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
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.