Description of problem: SELinux is preventing /usr/sbin/setfiles from 'write' accesses on the fifo_file /var/tmp/dracut.nkGOKQ/systemd-cat. ***** Plugin leaks (86.2 confidence) suggests ***************************** If you want to ignore setfiles trying to write access the systemd-cat fifo_file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/sbin/setfiles /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (14.7 confidence) suggests ************************** If you believe that setfiles should be allowed write access on the systemd-cat fifo_file 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: # grep restorecon /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:setfiles_t:s0 Target Context system_u:object_r:kdumpctl_tmp_t:s0 Target Objects /var/tmp/dracut.nkGOKQ/systemd-cat [ fifo_file ] Source restorecon Source Path /usr/sbin/setfiles Port <Unknown> Host (removed) Source RPM Packages policycoreutils-2.4-21.fc24.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-171.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.5.0-0.rc4.git3.1.fc24.x86_64 #1 SMP Fri Feb 19 19:38:12 UTC 2016 x86_64 x86_64 Alert Count 4 First Seen 2016-02-17 07:32:27 CET Last Seen 2016-02-22 08:18:24 CET Local ID 408f48d7-9b87-4e98-919c-8a21a6ba7fcc Raw Audit Messages type=AVC msg=audit(1456125504.398:290): avc: denied { write } for pid=6055 comm="restorecon" path="/var/tmp/dracut.nkGOKQ/systemd-cat" dev="dm-12" ino=1970268 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:object_r:kdumpctl_tmp_t:s0 tclass=fifo_file permissive=1 type=SYSCALL msg=audit(1456125504.398:290): arch=x86_64 syscall=execve success=yes exit=0 a0=55cf9b0126d0 a1=55cf9b015610 a2=55cf9b0c0650 a3=55cf9b015610 items=0 ppid=20868 pid=6055 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=restorecon exe=/usr/sbin/setfiles subj=system_u:system_r:setfiles_t:s0 key=(null) Hash: restorecon,setfiles_t,kdumpctl_tmp_t,fifo_file,write Version-Release number of selected component: selinux-policy-3.13.1-171.fc24.noarch Additional info: reporter: libreport-2.6.4.6.gadd53 hashmarkername: setroubleshoot kernel: 4.5.0-0.rc4.git3.1.fc24.x86_64 type: libreport
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
*** Bug 1367670 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Description of problem: I changed kdump.conf and ran: systemctl restart kdump.service Version-Release number of selected component: selinux-policy-3.13.1-225.3.fc25.noarch Additional info: reporter: libreport-2.8.0 hashmarkername: setroubleshoot kernel: 4.8.14-300.fc25.x86_64 type: libreport
Description of problem: On boot of new vmlinuz-4.8.15-200.fc24.x86_64 kernel Version-Release number of selected component: selinux-policy-3.13.1-191.21.fc24.noarch Additional info: reporter: libreport-2.7.2 hashmarkername: setroubleshoot kernel: 4.8.15-200.fc24.x86_64 type: libreport
Gosh, I could really use kdump right now. Is there a reason why this still happening? I just assume this system service would be granted the privileges it needs. Is there another workaround besides making a local policy?
*** This bug has been marked as a duplicate of bug 1356456 ***