SELinux/Logging

When SELinux denies a particular activity, it will usually log this through the audit subsystem or, if auditing is disabled, through the kernel logging. Usually, because SELinux policy developers can tell the SELinux subsystem not to log a particular denial. But even those settings can be overruled by the system administrator to have SELinux log all denials.

Introduction
SELinux bases its decisions (allow or deny) on policy rules. Whenever a particular activity is performed, its access vectors is taken by SELinux and checked with the access vector cache (AVC). This cache contains the access vectors together with the allow/deny state. If the access vector is allowed, then the operation can continue. If not, then the operation is dnied. If there is no specific  statement active, then an AVC denial will be logged in the audit subsystem.

This additional logging is extremely important to debug permission issues as "just" Permission Denied does not help us much. The denial logging contains a vast majority of information that administrators can use to troubleshoot permission issues further.

Format of an AVC denial
The following is an example AVC denial:

The structure of a denial depends on the denial type itself. The above denial is for file access, the following one is for a capability:

The most important part of the denial is the permission (between ), class (as referenced by the   parameter) and contexts (  for the source context, and   for the target context).

Reasons for denials
A denial is due to the SELinux policy. However, it is not always due to a missing access vector rule. For instance, the following denial might occur, even when a proper access vector rule is available for it:

In the above case, the denial came from a feature called User-Based Access Control, where resources of one SELinux user are not accessible for processes of another SELinux user.

Such a feature is implemented through SELinux constraints, which not only focuses on the types in a context ( and  ) but also the relation of SELinux users and SELinux roles.

In the vast majority of cases though, denials are due to missing access vector rules.

Listing recent AVC denials
To view the recent set of AVC denials through the audit subsystem, use :

The audit logs are usually also readable at but the time stamp displayed in the logs will need to be manually converted in that case (as it is not localized).

Clearing the audit logs
It is not recommended to clear the audit logs as they might contain information needed in the future for troubleshooting or security investigations. However, if that is not the case, just empty the audit log:

Disabling dontaudit statements
It is possible to rebuild the SELinux policy and disable the  statements. These statements are put in the policy by the SELinux policy developers to hide particular denials from the regular audit reporting, as the policy developer believes that the denial is cosmetic and can be ignored.

To rebuild and disable:

To re-enable the  statements, just rebuild the policy again:

Allowing an access vector
It is possible to allow a particular access vector by enhancing the currently loaded SELinux policy.

A rule can be added using the (Gentoo-only)  script:

Another possibility is to use  to build a SELinux policy module based on the audit events: