I've tried doing `restorecon` on the specified file, and on the whole /var/log/ directory, but verbose-mode restorecon does not report any changed files after completing. I also tried resetting the context for the whole filesystem (`touch /.autorelabel && reboot`). But I keep getting the message below anyway. I've noticed this happening occasionally in the past, usually a little more often shortly after reinstalling and reconfiguring my desktop, but now it's been happening a few times a day all week. My system setup: * Fedora 27 Workstation x86_64 * GNOME Shell 3.26.2-4.fc27 * selinux-policy 3.13.1-283.21.fc27 * systemd 234-9.fc27 --- SELinux is preventing 2F7573722F6C69622F73797374656D642F73797374656D642D6A6F75726E616C64202864656C6574656429 from search access on the directory /var/log/journal/4dc0f9aba562414390042ed94c9427fb. ***** Plugin restorecon (99.5 confidence) suggests ************************ If you want to fix the label. /var/log/journal/4dc0f9aba562414390042ed94c9427fb default label should be var_log_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /var/log/journal/4dc0f9aba562414390042ed94c9427fb ***** Plugin catchall (1.49 confidence) suggests ************************** If you believe that 2F7573722F6C69622F73797374656D642F73797374656D642D6A6F75726E616C64202864656C6574656429 should be allowed search access on the 4dc0f9aba562414390042ed94c9427fb directory 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 'systemd-journal' --raw | audit2allow -M my-systemdjournal # semodule -X 300 -i my-systemdjournal.pp Additional Information: Source Context system_u:system_r:syslogd_t:s0 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects /var/log/journal/4dc0f9aba562414390042ed94c9427fb [ dir ] Source systemd-journal Source Path 2F7573722F6C69622F73797374656D642F73797374656D642D 6A6F75726E616C64202864656C6574656429 Port <Unknown> Host pluto.localdomain Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-283.16.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name pluto.localdomain Platform Linux pluto.localdomain 4.13.9-300.fc27.x86_64 #1 SMP Mon Oct 23 13:41:58 UTC 2017 x86_64 x86_64 Alert Count 944 First Seen 2017-11-25 17:46:01 PST Last Seen 2017-11-25 17:46:47 PST Local ID 87ed4a9d-84d8-4293-a673-54a21fb2c0e3 Raw Audit Messages type=AVC msg=audit(1511660807.574:2031): avc: denied { search } for pid=1886 comm="systemd-journal" name="var" dev="dm-1" ino=276 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1511660807.574:2031): arch=x86_64 syscall=open success=no exit=EACCES a0=55ec9c3d2500 a1=90800 a2=7ffe7e8a60e8 a3=7ffe7e8a6090 items=1 ppid=1 pid=1886 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=2F7573722F6C69622F73797374656D642F73797374656D642D6A6F75726E616C64202864656C6574656429 subj=system_u:system_r:syslogd_t:s0 key=(null) type=CWD msg=audit(1511660807.574:2031): cwd=/ type=PATH msg=audit(1511660807.574:2031): item=0 name=/var/log/journal/4dc0f9aba562414390042ed94c9427fb nametype=UNKNOWN cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 Hash: systemd-journal,syslogd_t,user_home_t,dir,search
"/var/log/journal/4dc0f9... default label should be var_log_t." and yet... ↪ secon --file /var/log/journal/4dc0f9aba562414390042ed94c9427fb user: system_u role: object_r type: var_log_t sensitivity: s0 clearance: s0 mls-range: s0 The file is already in the context that SELinux Troubleshooter says it should be. So why does it keep reporting this non-problem?
selinux-policy was updated a couple weeks ago, and I haven't noticed the Troubleshooter complain about journal file in a while. So either you guys fixed it or the problem went away on its own because magic :)
Or maybe not? Troubleshooter has resumed daily warnings about this exact issue again. (Currently on selinux-policy-3.13.1-283.28.fc27)
selinux-policy-3.13.1-284.37.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4bb4de2d86
selinux-policy-3.13.1-284.37.fc27 has been pushed to the Fedora 27 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-2018-4bb4de2d86
selinux-policy-3.13.1-284.37.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.