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)> \
<permission(s)> |
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:
allow — permit a
subject to act in a specific way with an object. The rule here allows
named (in the domain of named_t) to
perform a search of a directory with the type
sbin_t (for example,
/sbin, /usr/sbin,
/opt/sbin, etc.):
allow named_t sbin_t:dir search; |
If the ruling results in a denial, the denial is audited (that is,
logged). Granted permission events are not logged.
auditallow — when the
permission is granted, log the access decision. In the targeted
policy, there is only one auditallow
rule. This rule logs usage of certain SELinux applications, for example
logging avc: granted { setenforce }
when allowing setenforce:
auditallow unconfined_t security_t : security { load_policy \
setenforce setbool }; |
dontaudit — never audit a
specific access denial. This is used when a program is attempting an
action that is not allowed by policy, and the resulting denials are
filling the log, but the denial is not affecting the application doing
its tasks. This AV lets you silently deny and ignore the access
violation. For example, this
dontaudit rule says to ignore when
the named_t domain attempts to read
or get attributes on a file with the
root_t type. Denial of this access
attempt does not effect named doing its job, so the denial is
ignored to keep the logs clean:
dontaudit named_t root_t:file { getattr read }; |
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":
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.
- hostname
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.
- exe=/usr/sbin/httpd
The application being denied.
- path=/home/auser/public_html
The path to the target file or directory the operation was
attempted on.
- dev=hdb2
The device node that holds the file system. The object of the
denied operation lives in this file system.
- ino=921135
The inode number of the target file or directory.
- scontext=root:system_r:httpd_t
The security context of the source, that is, the process being
denied access.
- tcontext=user_u:object_r:user_home_t
The security context of the target, that is, the file or
directory that is denied.
- tclass=dir
The object class of the target, indicating
that it was the directory
/home/auser/public_html/ that was being
blocked.