Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: An SELinux messages storm was caused by trying to start rsyslog with the "immark" module enabled: # auditctl -w /etc/shadow -p w Error sending add rule data request (Rule exists) # systemctl start rsyslog && systemctl stop rsyslog # systemctl status rsyslog | grep -m1 fopen May 17 17:55:44 horus rsyslogd[28529]: imjournal: fopen() failed for path: '/imjournal.state.tmp': Permission denied [v8.34.0 try http://www.rsyslog.com/e/2013 ] # ausearch -m avc -ts recent | tail -1 type=AVC msg=audit(1526604944.491:101110): avc: denied { dac_override } for pid=28529 comm="rsyslogd" capability=1 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=capability permissive=0 # ausearch -m avc -ts recent | wc -l 147 == Apparently there is a syntax error in /etc/rsyslog.conf: # dnf download rsyslog # rpm2cpio < rsyslog*.rpm | cpio -id ./etc/rsyslog.conf # diff /etc/rsyslog.conf etc/rsyslog.conf 15c15 < module(load"immark") # provides --MARK-- message capability --- > #module(load"immark") # provides --MARK-- message capability => By simply removing the # from the immark line in the configuration file that is shipped with the package, one introduces a syntax error: it should've read load="immark", with an "=" included. Once this has been fixed, rsyslog starts and the AVC errors are gone too. While a syntax error may prevent an application not to start or to function properly, it should not cause an AVC message storm. This is a desktop system and with every alert, the SELinux Troubleshooter displays another desktop notification about that alert and the machine got busy pretty quickly trying to display those notifications. That's why I report this agains the selinux package, instead of the application (rsyslog) that triggered this. SELinux is preventing in:imjournal from using the 'dac_override' capabilities. ***** Plugin dac_override (91.4 confidence) suggests ********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that in:imjournal should have the dac_override capability 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 'in:imjournal' --raw | audit2allow -M my-inimjournal # semodule -X 300 -i my-inimjournal.pp Additional Information: Source Context system_u:system_r:syslogd_t:s0 Target Context system_u:system_r:syslogd_t:s0 Target Objects Unknown [ capability ] Source in:imjournal Source Path in:imjournal Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.1-24.fc28.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.16.8-300.fc28.x86_64 #1 SMP Wed May 9 20:23:40 UTC 2018 x86_64 x86_64 Alert Count 3313 First Seen 2018-05-17 17:39:51 PDT Last Seen 2018-05-17 17:55:44 PDT Local ID 9f53de36-0d9a-4404-8c83-3b9465b2cd91 Raw Audit Messages type=AVC msg=audit(1526604944.491:101110): avc: denied { dac_override } for pid=28529 comm="rsyslogd" capability=1 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=capability permissive=0 Hash: in:imjournal,syslogd_t,syslogd_t,capability,dac_override Version-Release number of selected component: selinux-policy-3.14.1-24.fc28.noarch Additional info: component: selinux-policy reporter: libreport-2.9.5 hashmarkername: setroubleshoot kernel: 4.16.8-300.fc28.x86_64 type: libreport
*** Bug 1599568 has been marked as a duplicate of this bug. ***
Taking this and re-targeting to rawhide, thanks to Radovan analysis a typo was found in commented-out section of rsyslog config which causes it to try to create its state file in "/" rather than its working directory. I will fix a typo and reorder the config file to reduce a chance of similar things in the future.
link to commit: https://src.fedoraproject.org/rpms/rsyslog/c/c0f7639d4ef87010bab2dc49e3ef1c9d4b26bc2c?branch=master
For stable version I will fix it with next rebase (upstream release scheduled in 2 weeks).
rsyslog-8.37.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2818fc5308
rsyslog-8.37.0-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-749f2bae28
rsyslog-8.37.0-1.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-2818fc5308
rsyslog-8.37.0-1.fc28 has been pushed to the Fedora 28 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-749f2bae28
rsyslog-8.37.0-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
rsyslog-8.37.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.