Contents

Access Vector Rules

The AV rules define what access control privileges are allowed for processes. There are four types of AV rule: allow, dontaudit, auditallow, and neverallow as explained in the sections that follow with a number of examples to cover all the scenarios. There is also an auditdeny rule, however it is no longer used in the Reference Policy and has been replaced by the dontaudit rule.

The general format of an AV rule is that the source_type is the identifier of a process that is attempting to access an object identifier target_type, that has an object class of class, and perm_set defines the access permissions source_type is allowed.

One or more source / target type or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}). Entries can be excluded from the list by using the negative operator (-).

The target_type can have the self keyword instead of type or attribute identifiers. This means that the target_type is the same as the source_type.

The neverallow rule also supports the wildcard operator (*) to specify that all types are to be included and the complement operator (~) to specify all types are to be included except those explicitly listed.

class

One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).

perm_set

The access permissions the source is allowed to access for the target object (also known as the Access Vector). Multiple entries consist of a space separated list enclosed in braces ({}).

The optional wildcard operator (*) specifies that all permissions for the object class can be used.

The complement operator (~) is used to specify all permissions except those explicitly listed (although the compiler issues a warning if the dontaudit rule has '~').

The statements are valid in:

Monolithic Policy

Base Policy

Module Policy

Yes

Yes

Yes

Conditional Policy (if) Statement

optional Statement

require Statement

allow = Yes

auditallow = Yes

dontaudit = Yes

neverallow = No

allow = Yes

auditallow = Yes

dontaudit = Yes

neverallow = Yes

allow = No

auditallow = No

dontaudit = No

neverallow = No

allow Rule

The allow rule checks whether the operations between the source_type and target_type are allowed. It is the most common statement that many of the Reference Policy helper macros and interface definitions expand into multiple allow rules.

Examples:

# Using the allow rule to show that initrc_t is allowed access
# to files of type acct_exec_t that have the getattr, read and
# execute file permissions:
allow initrc_t acct_exec_t:file { getattr read execute };

# This rule includes an attribute filesystem_type and states
# that kernel_t is allowed mount permissions on the filesystem
# object for all types associated to the filesystem_type
# attribute:
allow kernel_t filesystem_type:filesystem mount;

# This rule includes the self keyword in the target_type that
# states that staff_t is allowed setgid, chown and fowner
# permissions on the capability object:
allow staff_t self:capability { setgid chown fowner };
# This would be the same as the above:
allow staff_t staff_t:capability { setgid chown fowner };

# This rule includes the wildcard operator (*) on the perm_set
# and states that bootloader_t is allowed to use all permissions
# available on the dbus object that are type system_dbusd_t:
allow bootloader_t system_dbusd_t:dbus *;
# This would be the same as the above:
allow bootloader_t system_dbusd_t:dbus { acquire_svc send_msg };

# This rule includes the complement operator (~) on the perm_set
# and two class entries file and chr_file.
#
# The allow rule states that all types associated with the
# attribute files_unconfined_type are allowed to use all
# permissions available on the file and chr_file objects except
# the execmod permission when they are associated to the types
# listed within the attribute file_type:
allow files_unconfined_type file_type:{ file chr_file } ~execmod;

dontaudit Rule

The dontaudit rule stops the auditing of denial messages as it is know that this event always happens and does not cause any real issues. This also helps to manage the audit log by excluding known events.

Example:

# Using the dontaudit rule to stop auditing events that are
# known to happen. The rule states that when the traceroute_t
# process is denied access to the name_bind permission on a
# tcp_socket for all types associated to the port_type
# attribute (except port_t), then do not audit the event:
dontaudit traceroute_t { port_type -port_t }:tcp_socket name_bind;

auditallow Rule

Audit the event as a record as it is useful for auditing purposes. Note that this rule only audits the event, it still requires the allow rule to grant permission.

Example:

# Using the auditallow rule to force an audit event to be
# logged. The rule states that when the ada_t process has # permission to execstack, then that event must be audited:
auditallow ada_t self:process execstack;

neverallow Rule

This rule specifies that an allow Rule must not be generated for the operation, even if it has been previously allowed. The neverallow statement is a compiler enforced action, where the checkpolicy or checkmodule compiler checks if any allow rules have been generated in the policy source, if so it will issue a warning and stop.

Examples:

# Using the neverallow rule to state that no allow rule may ever
# grant any file read access to type shadow_t except those
# associated with the can_read_shadow_passwords attribute:
neverallow ~can_read_shadow_passwords shadow_t:file read;

# Using the neverallow rule to state that no allow rule may ever
# grant mmap_zero permissions any type associated to the domain
# attribute except those associated to the mmap_low_domain_type
# attribute (as these have been excluded by the negative
# operator (-)):
neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;