User:SwifT/selinux-tutorials/2b

Where to find SELinux permission denial details
Now that you are aware that SELinux governs file access by verifying the security context of the process (the domain) and the context of the file, it is time to find out how, if SELinux denies a certain access, you can troubleshoot this in more detail.

SELinux logging
The most important feature of SELinux, and one you should start learning by heart, is that it is able to log everything. And with everything, I mean everything. If you want, we can have SELinux log all granted accesses (although I can imagine that becomes dull to look at, and might slow down the performance of the system), but more importantly it logs access denials.

The default location where you can find this logging depends a bit on the distribution, but generally it is either in if you are not running the Linux audit daemon, and in  or  if you are. This logging is very verbose, mainly because you need many details in order to troubleshoot problems.

But before we take a look at the denials, we also want to give you a heads up. Mar 12 17:46:42 hpl kernel: [  14.453644] audit_printk_skb: 84 callbacks suppressed
 * 1) Not every denial you find in the logs is a problem by itself. Some denials are cosmetic, meaning that they do occur but do not influence the behavior of an application. This is often because of an application development malpractice (like not properly closing file descriptors) or because of high-level library functions where only a small fraction of the features are used by an application.
 * 2) Denials are logged as they come along. That means that you will see a lot of denials, and although many will be related to each other (one denial leads to the other) many will also have nothing to do with the problem you are investigating.
 * 3) If there are too many denials succeeding each other, they might be suppressed by the Linux kernel; if that happens, you will get a message like the following, so if you find this message in your logs you have to understand that you are not seeing everything that SELinux might be reporting:

So let's take a look at one denial. This one comes from the audit log (which you can tell from the start of the log, type=AVC, which you will not see in the as it is implied there).

type=AVC msg=audit(1363289005.532:184): avc: denied  { read } for  pid=29199 comm="Trace" name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t tcontext=system_u:object_r:sysfs_t tclass=file

We warned you that it was verbose ;-)

Disecting the AVC denial
AVC stands for Access Vector Cache. Not that that is worth much right now, but the word cache does already give you feedback as to why the logs might not show everything if SELinux had too many things to report. Just thought it might interest you (since the term avc denial might show up in documentation). But let's get back to the denial we had.

type=AVC msg=audit(1363289005.532:184): avc: denied  { read } for  pid=29199 comm="Trace" name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t tcontext=system_u:object_r:sysfs_t tclass=file

Once you get to know this denial structure, you can translate this into the following:


 * The Trace process with PID 29199 tried to read a file called on a file system hosted on the sysfs device. This file has inode number 30, and has the security context system_u:object_r:sysfs_t assigned to it. The Trace process itself is running with the staff_u:staff_r:googletalk_plugin_t context (domain).

You probably find the details from the translated sentence back in the denial easily, but I'm going to disect the denial part by part anyway.