anyone please explain me how to read a AVC in the audit log?

seems too complicated.

Like-

type=AVC msg=audit(1226270358.848:238): avc: denied { write } for pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir

thanks

It does seem very complicated but its because it has everything you need to figure out the problem. First if you got this from the audit log try to use ausearch instead. If you use that with the -i option it will interpret all the numerical values it can into something sensible. This is very useful for syscall audit entries as well.

What you are looking at is the genral format of an audit message. The type of this message is AVC meaning it is from SELinux and in this case is a permission denial (instead of a constraint violation). The words in the curly braces are the action that the application tried to take. In this case it attempted to write to something it didn't have access to. The pid and comm fields are the pid of the offending process and the name of the command which was run (typically what you would find in argv[0]). The name field is the name of the object that certwatch wanted to access in this case a directory called cache. We know this is a directory by looking at the tclass flag below (tclass stands for target class). The target class is the type of object that the program was wanting to access in this case dir. The dev and ino information tell you what device and inode number the file was on. The remaining 3 fields are very SELinux specific.

SELinux rules exist in this form. A process running with this label (in this case certwatch_t) can access an object of a given class with a given type. In this case a denial happened because there is no rule to say that a process running as certwatch_t can access a directory labeled var_t.

So to write it out in plain english we can say:

SELinux encountered a permission denial: The program certwatch running with the label certwatch_t attempted to write to a directory named cache labeled var_t which is on device dm-0 with inode number 218171. There was no rule in the policy that allowed this program to access this directory.

this is very nice post