FAQ: SELinux denies access but AVC denials can not be found.

It happens. There are a few reasons for this:

1. Silenced AVC denials (access vector cache).

In policy one can define to silently deny access vectors. This means access is denied and attempts are not logged. Such a rule (access vector) would look like this for example (fictional):

dontaudit user_t var_t:dir { read open };

When a user that operates in the user_t user domain tries to read a var_t directory object type, access is denied. The attempt that was denied would not be logged.

In general the use of "dontaudit" rules should be kept to a minimum. The issue of being denied access and not finding an audit trail for this reason should not happen often at all.

There are exceptions, like restricted user domains. These processes are restricted/limited for reason and those restrictions/limits might give violation attempts when a user operating in such a domain tries to do something that is not allowed. In this case the AVC denials are anticipated and silenced to avoid flooding of the logs with meaning less entries.

There is a way to expose these silenced AVC denials, but be aware that this may fill up your logs quicker than expected.

The semodule command used with the -DB options unloads "dontaudit" rules on-the-fly. All attempts to violate policy are now logged.

The semodule command used with the -B option builds the policy with the "dontaudit" rules included. Silenced AVC denials are back in policy.

2. User space object managers.

User space object managers are SELinux extensions on application layers. Applications that implement a SELinux Access Control Extension provides classes and permissions to be used for SELinux Policy. The application itself enforces policy that is defined using the classes and permissions it has provided.

There are only few applications that are also user space object managers. DBus implements this and this feature is enabled by default. If some access is denied and you've unloaded the "dontaudit" rules using the semodule command with -DB option, but you still cannot find any audit trail, then chances are the DBUS access control extension is responsible.

In some cases, which might be due to a bug, DBUS sends its user_avc denials to /var/log/messages instead of the expected /var/log/audit/audit.log

So it is recommended to also see /var/log/messages or dmesg if you suspect SELinux denied access but you cannot find any audit trail.

SELinux denials are called AVC denials and can also be listed using the ausearch command with -m option and avc parameter.

User space object manager denials are called USER_AVC denials and can also be listed using the ausearch command with the -m option and user_avc parameter. Note that this only works for denials logged to /var/log/audit/audit.log

Conclusion:

If you suspect SELinux denied some access but you can not find the audit trail then consider building the policy without the "dontaudit" rules using semodule -DB. If you still cannot find any audit trail than maybe a user space object manager denied access. Look for USER_AVC denials in audit.log or look in /var/log/messages, or dmesg. The log file for the application itself may also have them.

I think the goal is to have everything log to audit.log for simplicity but at the moment this is not the case.

Tip:

You can use the sesearch command to list "dontaudit" rules that are currently built-in policy. For example to list "dontaudit" rules where the httpd_t is the source domain:

sesearch --dontaudit -s httpd_t

Have a look at "man sesearch"