2.8. TE Rules - Access Vectors

CentOS 6 Essentials
eBook

$9.99

eBookFrenzy.com

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":

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

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