Decide if you wish to send Linux audit messages to a central server. Doing so could get the audit trail off the hosts in case something happens to them. And analysis could happen on a separate logging host, simplifying monitoring many hosts and reducing some small performance impact of analysis on production hosts.
However, the default setup in selinux policy troubleshooting tools is to analyze the local host. As this is a simple way to get suggestions on your policy denials, try it and see how it works.
setroubleshoot-server package contains the pieces making this tool work.
- auditd executes sedispatch as a plugin
- sedispatch finds AVC messages and send on dbus
- setroubleshootd is the Python analysis script taking a guess at what the denials mean
- sealert is the tool you use to get the parsed denials, notably as
sealert -l '*' or sealert -a
The dbus service enforces running as a certain user. setroubleshoot for analysis, root for fixes. Audit logs can be sensitive information and should not be edited. A dedicated user allows restrictive access to the data, and running the fancy program with reduced privileges.
setroubleshootd.service is a dbus activated systemd service. You do not start this unit with systemctl commands, and it is not always active with the program running. Rather, it listens on dbus to a certain name. Which has the advantage of not executing the program (as the correct user) until sedispatch sends it some messages, and it can go inactive until more arrive.
As a systemd service setroubleshootd can be resource limited and usually is out of the box, tweak that with drop in config files if desired. On a host that is not severely resource constrained, running a Python program on a few lines of text is a small administrative overhead. Personally I would want some evidence of a performance issue before spending too much time on this, ideally indicators of real contention like Linux pressure stall information.
A useful test would be to actually send some denials through the system. If you are lucky enough to have quiet logs, create some based on selinux policy you already know. For example, start httpd on non-default ports, but do not set selinux ports. You might observe setroubleshootd running, although maybe only for a short time.
If you do not use sealert at all, removing the entire setroubleshoot* packages is an obvious way to not use it permanently. I am skeptical of the performance hit unless processing a large volume of messages, although if not using at all there is no point in keeping it around. In theory, could disable the sedispatch plugin without removing it, but then you would need to remember that it is off in configuration.
