3.6. Logging and Auditing

SELinux logs all its messages to the system log, or to the audit log if running under Fedora Core with the auditd daemon running.

3.6.1. Reading Log Entries

Reading log entries is the bread and butter of SELinux administration. All troubleshooting of SELinux denials, as well as development of new security policy, involves reading the logs for SELinux denials.

type=AVC msg=audit(1117726540.077:9322426): avc: denied { read } for pid=10652 comm="tail" name=audit.log dev=dm-0 ino=328749 scontext=root:staff_r:staff_t tcontext=system_u:object_r:auditd_log_t tclass=file

The above logged denial tells an administrator that SELinux denied a read attempt on the file audit.log using the tail command. The source process context was root:staff_r:staff_t, and the targeted file's context was system_u:object_r:auditd_log_t. We know from this that the staff_t domain has no read access to the auditd_log_t file type. This is as it should be, if we had used a newrole command to transition to the sysadm_r role we would be running tail in the sysadm_t domain and access would have been granted.

3.6.2. audit2allow

audit2allow is a perl script that reads logged denials and turns them into rules that can be added to SELinux policy to thereafter allow the operations that were denied. It is not intended as an automatic policy generator, but as an aid to developing policy. audit2allow output should always be read carefully before adding it to the system policy, as it may allow more access than strictly necessary for the application involved. The tool is best used as a guideline when writing policy, not as an actual generator of policy itself. See Section 4.6 for examples of the use of audit2allow.

3.6.3. Log Rate Limiting

SELinux will sometimes limit the amount of log entries it writes during periods of high activity, in order to prevent flooding the logs with repeated entries of the same denial. This can cause difficulty when troubleshooting, as a denial can be occasionally made with no corresponding log entry.

There is currently no way of knowing when the rate limiting has been triggered. In the future it is planned to migrate SELinux to its own logging solution, but for now system administrators must keep in mind that log enties may be lost during periods of high activity.