0

I have found a SELinux problem with logrotate. I'm just wondering why it was reported in /var/log/messages, and not in /var/log/audit/audit.log. I assumed that any SELinux issue gets logged into audit.log. Can anyone explain the reason?

I encountered this behaviour on a RHEL 8 system. Found entry in messages:

Nov 22 03:23:14 itsrv2489 setroubleshoot[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6. For complete SELinux messages run: sealert -l 2c99b2ca-3bf0-486d-b1c3-54bc6e87105e
Nov 22 03:23:14 itsrv2489 platform-python[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that logrotate should be allowed read access on the g6 directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'logrotate' --raw | audit2allow -M my-logrotate#012# semodule -X 300 -i my-logrotate.pp#012

These two lines from above formatted by me:

Nov 22 03:23:14 itsrv2489 setroubleshoot[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6. 
For complete SELinux messages run: 
sealert -l 2c99b2ca-3bf0-486d-b1c3-54bc6e87105e

Nov 22 03:23:14 itsrv2489 platform-python[2468163]: SELinux is preventing logrotate from read access on the directory /var/www/html/g6.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that logrotate should be allowed read access on the g6 directory by default.

Then you should report this as a bug.
You can generate a local policy module to allow this access.

allow this access for now by executing:
# ausearch -c 'logrotate' --raw | audit2allow -M my-logrotate
# semodule -X 300 -i my-logrotate.pp

Usually I see such entries in /var/log/audit/audit.log.

Update: Finally I've found out, that audit.log was rotated itself and since it was very large some records were dropped. That's the reason why I could not find the key word 'logrotate' in those audit log files. I modified /etc/audit/auditd.conf to disable rotation and on the next day I was able to find 'logrotate' in the audit.log (gets triggered by cron job, once a day).

Improve this question
4
  • Are you saying the issue hasn't been reported in audit.log? Commented Nov 25, 2020 at 13:57
  • @ArtemS.Tashkinov Yes, exactly. Is that strange? Commented Nov 25, 2020 at 21:05
  • Now I get the impression, that I might not find 'logrotate' in audit.log because it was rotated by auditd and some files were therefore deleted. I turned that off and wait what happens (finding 'logrotate' in audit.log tomorrow). Commented Nov 25, 2020 at 21:42
  • 1
    That's what I thought :-) There's no way there's an audit related event logged in /var/log/messages without a corresponding record in audit.log Commented Nov 26, 2020 at 0:13

1 Answer 1

Reset to default
1

audit.log does get the raw SELinux deny messages, that's true.

But the messages you're looking at are not generated directly by SELinux itself. Instead, they are logged by setroubleshoot: a Python tool which post-processes the SELinux audit log messages and provides more human-readable, higher-level interpretations of them.

The audit log is dedicated to the audit subsystem only: since setroubleshoot is not an actual part of the audit subsystem, it needs to log its messages elsewhere. So it logs to /var/log/messages instead.

Improve this answer
2
  • Well explained, thank you! One question: Does this also imply that any SELinux report, that I can see with sealert -a /var/log/audit/* can also be found in /var/log/messages? Commented Nov 26, 2020 at 16:57
  • sealert and setroubleshootd are both parts of the setroubleshoot system. setroubleshootd analyzes SELinux events as they arrive and produces higher-level messages in /var/log/messages. With sealert -a, you can re-process the audit logs through the setroubleshoot system interactively, e.g. if the setroubleshootd service was not running at the time of the situation you're interested in. So if you always have setroubleshootd running, the short answer would be yes. Commented Nov 26, 2020 at 18:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.