2.8. TE Rules - Access Vectors

Access vectors (AVs) are the rules that allow domains to access various system objects. An AV is a set of permissions. A basic AV rule is a subject and object pair of types, a class definition for the object, and a permission for the subject. There is a general rule syntax that covers all the kinds of AV rules:

<av_kind> <source_type(s)> <target_type(s)>:<class(es)> \

All AV rules are considered by the policy enforcement engine as two types, one class, and one access permission. However, rules are written using attributes, sets, and macros to be more efficient. AV rules are simplified during policy compilation.

The parts of the AV rule are defined elsewhere in this chapter. This section describes the kinds of access vectors used in the AV rule at av_kind. av_kind is one of three rule types:

There is one additional AV rule, neverallow. This AV assertion, defined in $SELINUX_SRC/assert.te, is not part of the regular permission checking. The purpose of this rule is to declare access vectors that must never be allowed. These are used to protect against policy writing mistakes, especially where macros can provide unexpected rights. These assertions are checked by the policy compiler, checkpolicy, when the policy is built, but after the entire policy has been evaluated, and are not part of the runtime access vector cache.

Here is the syntax and an example. In practice, a wildcard character * is often used to cover all instances possible in a rule field. The syntax is different in that it is possible to use ifdef() statements as sources or targets:

# Syntax for AV assertion

neverallow <source_name(s)> <target_name(s)> : \
  <class(es)> <permission(s)>

In this example from assert.te, the neverallow rule verifies that every type that a domain can enter into has the attribute domain. This prevents a rule from elsewhere in the policy allowing a domain to transition to a type that is not a process type. The tilde in front, ~domain, means "anything that is not a domain":

# Verify that every type that can be entered by
# a domain is also tagged as a domain.
neverallow domain ~domain:process transition;

2.8.1. Understanding an avc: denied Message

When SELinux disallows an operation, a denial message is generated for the audit logs. In Red Hat Enterprise Linux, $AUDIT_LOG is /var/log/messages. This section explains the format of these log messages. For suggestions on using an avc: denied message for troubleshooting, refer to Section 5.2.11 Troubleshoot User Problems With SELinux.

Example 2-1 shows a denial generated when a user's Web content residing in ~/public_html does not have the correct label.

Jan 14 19:10:04 hostname kernel: audit(1105758604.519:420):  \
avc:  denied  { getattr } for  pid=5962 exe=/usr/sbin/httpd \
path=/home/auser/public_html dev=hdb2 ino=921135 \
scontext=root:system_r:httpd_t \
tcontext=user_u:object_r:user_home_t tclass=dir

Example 2-1. AVC Denial Message

This shows the message parts and an explanation of what the part means:

avc: denied Message Explained

Jan 14 19:10:04

Timestamp on the audit message.


The hostname of the system.

kernel: audit(1105758604.519:420):

This is the kernel audit log message pointer. The timestamp consists of a long number, which is the unformatted current time, and a short number, which is the milliseconds, that is, <current_time>.<milliseconds_past_current_time>. The third number is the serial number, which helps in stitching together the full audit trail from multiple messages. Multiple messages for the same event occur when full audit logging is enabled using an audit daemon, which logs various kernel events.

avc: denied

The operation was denied. A few operations have auditallow set so they generate granted messages instead.

{ getattr }

What was denied or granted. The brackets {} contain the actual permission that was attempted.

for pid=5962

The process ID of the application that is the source of the operation.


The application being denied.


The path to the target file or directory the operation was attempted on.


The device node that holds the file system. The object of the denied operation lives in this file system.


The inode number of the target file or directory.


The security context of the source, that is, the process being denied access.


The security context of the target, that is, the file or directory that is denied.


The object class of the target, indicating that it was the directory /home/auser/public_html/ that was being blocked.