Welcome to Linux Forums! With a comprehensive Linux Forum, information on various types of Linux software and many Linux Reviews articles, we have all the knowledge you need a click away, or accessible via our knowledgeable members.
Find the answer to your Linux question:
Site Navigation
Linux Forums
Linux Articles
Product Showcase
Linux Downloads
Linux Hosting
Free Magazines
Job Board
IRC Chat
RSS Feeds
Free Publications

This is for those admins who were working on something, and suddenly a star pops up -- The AVC message warning. You start muttering under your breath and wonder where your day will end up?

Riders:  1) You should know what SELinux is about.

              2) audit daemon must be running on your system.

              3) SELinux must be in enforcing mode.

              4) You must understand what the AVC message means. Do not go about doing this with every AVC: Denied message or you are going to definitely land in big trouble.


Let's kick off.

I will give you a real life example of the situation, I have faced, and the way I resolved it.

I am running a DNS server on my Fedora system. Recently, there were some issues with my primary DNS server not being able to transfer zone records, on to a secondary DNS server. I edited my /etc/named.conf file, so that any zone transfers are logged to a specific file in /var/log

Lets say the file would be transfer.log. The path would be /var/log/tranfer.log.

I created the file in the path specified. Unfortunately, with SELinux enabled, we have to worry about the "Security Contexts". But, then I surmised that I could use the "chcon" command, later, to change the Security Context of the file transfer.log. The "touch" command created an empty file.

To check the Securtiy Context, "ls -Z <file_name>" command was used. 

ls -Z tranfer.txt 
-rw-r--r-- root root unconfined_u:object_r:var_log_t:s0 transfer.log

The issue here is that transfer.log has to be written by the named service. As soon as the named service was restarted, the dreaded AVC: Denied

pop up appeared.

The error was:

type=AVC msg=audit(1247465930.147:397): avc: denied { append } for pid=21828 comm="named" name="transfer.log" dev=sda1 ino=335255 scontext=unconfined_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

type=SYSCALL msg=audit(1247465930.147:397): arch=40000003 syscall=5 success=no exit=-13 a0=b8093ea8 a1=441 a2=1b6 a3=440 items=0 ppid=21825 pid=21828 auid=500 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=1 comm="named" exe="/usr/sbin/named" subj=unconfined_u:system_r:named_t:s0 key=(null)

The gut reaction of most admins is to turn off the blasted SELinux feature, and get it over with. But if you are the never give up types, read on.
Lets break down the gibberish. First off it is clear that the offense has something to with our file transfer.log, see snippet above.  Next we have the scontext, or the source context of the process which is being denied access. The following part in italics, is the target context,which gives us the target file context. Lets summarise this.

Named was trying to write to transfer.log, but because of  different security contexts, was unable to do so. How do I know it is named?,see the exe="/usr/sbin/named" part, above. The commands "chcon" or "restorecon" will not work, here.  The issue here is the type enforcement. The named process has type "named_t" whereas our file transfer.log has type "var_log_t".

So what do we do?  The rescuer ---> "audit2allow" command.
This command will create a SELinux module for us that will allow named to write to our file transfer. Sice the audit daemon is running, we know that these AVC messages are logged in /var/log/audit/audit.log. Open the audit.log file and find the offending AVC message. Copy the complete message and put it in a new file say: auditsp.log. Run the following command:

audit2allow -m local -l -i /var/log/audit/auditsp.log > local.te

This will create a local.te type enforcement file. The file will look something like this:

module local 1.0;

require {
type named_t;
type var_log_t;
class file append;

#============= named_t ==============
allow named_t var_log_t:file append;

Don't lose your sleep over what it means, although you can make out that this file is talking about allowing named_t to append to var_log_t. Good enough!

The next set of commands are:

checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod 

semodule -i local.pp 

The "checkmodule" package must be installed on your computer. "checkmodule" will create a local.mod, module file. "semodule_package" creates the module package local.pp. "semodule -i" adds the package to the kernel. The adding part will take some time so dont fret about it.

In my case, I was able to successfully log zone-transfers to the file I created in /var/log/, after completing the above process. You may have different issues, so modify this tutorial to meet your needs.

Another piece of advice: Please use search engines to read more about SELinux, and the various commands. SELinux can become quite a pain if you dive into it headlong, without any knowhow. 

Rate This Article: poor excellent
Comments about this article

Comment title: * please do not put your response text here