sealert is the user interface component (either GUI or command line) to the setroubleshoot system. setroubleshoot is used to diagnose SELinux denials and attempts to provide user friendly explanations for a SELinux denial (e.g. AVC) and recommendations for how one might adjust the system to prevent the denial in the future.
In a standard configuration setroubleshoot is composed of two components, setroubleshootd and sealert.
setroubleshootd is a system daemon which runs with root privileges and listens for audit events emitted from the kernel related to SELinux. When the setroubleshootd daemon sees an SELinux AVC denial it runs a series of analysis plugins which examines the audit data related to the AVC. It records the results of the analysis and signals any clients which have attached to the setroubleshootd daemon that a new alert has been seen.
sealert can be run in either a GUI mode or a command line mode. In both instances sealert run as a user process with the privileges associated with the user. In GUI mode it attaches to a setroubleshootd server instance and listens for notifications of new alerts. By default the setroubleshootd server instance is the one on the local machine, however one can connect via TCP to another server instance on another machine. When a new alert arrives it alerts the desktop user via a notification in the status icon area. The user may then click on the alert notification which will open an alert browser. In addition to the current alert sealert communicates with the setroubleshootd daemon to access all prior alerts stored in the setroubleshoot database.
The user may elect to tag any given alert as being "silent" in the browser which prevents any future notification for the given alert. This is useful when a user is already aware of a reoccurring problem. Alerts may be deleted in the browser by selecting one or more alerts and using the menu item to mark them for deletion. The marked alerts are not actually deleted until the user selects the command to delete all alerts marked for deletion. This is analogous to many popular IMAP email clients. The user may elect to hide in the browser alerts marked for deletion and/or alerts which have been marked as silent, this helps keep the browser less cluttered.
In addition to alerts provided by the setroubleshoot daemon the "Scan Logfile" menu item provides the user with the ability to scan a log file which may contain audit messages, run the same analysis on the audit messages as the setroubleshootd daemon would done and then browse the alerts generated by the log file scan. The user may switch back and forth between "audit" alerts from the daemon and "logfile" alerts generated by the scan.
sealert may also be run in command line mode. The two most useful command line options are -l to "lookup" an alert ID and -a to "analyze" a log file. When setroubleshootd generates a new alert it assigns it a local ID and writes this as a syslog message. The -l lookup option may then be used to retrieve the alert from the setroubleshootd alert database and write it to stdout. This is most useful when setroubleshootd is being run on a headless system without the GUI desktop alert facility. The -a analyze option is equivalent to the "Scan Logfile" command in the browser. The log file is scanned for audit messages, analysis is performed, alerts generated, and then written to stdout. In both cases the -H option can be used to cause the alert to be written out in HTML format rather than the default plain text.
Log file scanning may be initiated from the sealert browser via the File::ScanLogFile menu or from the command line via 'sealert -a filename'. Please note that sealert runs as a user level process with the permissions of the user running it. Many system log files are readable by root only. To work around this if you have root access one can copy the file as root to a temporary file and change it's permissions. This is a good solution when scanning via the GUI as a normal user. Or you might consider su'ing to root and run the analysis via the command line (e.g. sealert -a filename).
The audit records in the log file must be valid syntactically correct audit messages or the parser will ignore them.
If you use the GUI browser to scan a log file you should be aware the browser can track and display alert reports from two simultaneous sources, either the alerts from the setroubleshootd server which is connected to the audit system or the alert reports from a log file scan. The View menu has entries which allow you to toggle between viewing the audit system reports and the scanned file reports.