Chapter 4. SELinux Policy

The policy is central to SELinux operation, since any operation not explicitly permitted in the policy will be denied by default. The policy also declares the default security contexts for every file on the system.

Policy is stored as a binary file, compiled from source. The source is not required to be present on the system to use SELinux, but policy cannot be modified without recompiling from source. This means that when installing new software either the policy must already contain rules for the new software or the policy must have these rules added and be recompiled. Keeping rules for uninstalled software in the binary policy will result in greater memory usage by the policy, but not keeping those rules will require a policy recompile after any software installation.

Policy rules and macros are saved as .te files in the domains/program subdirectory of the source tree before compiling into the binary policy, and file contexts are saved as .fc files in the file_contexts/program subdirectory. The files in these directories are the bulk of the SELinux policy, and the ones that system adminstrators will need to work with when adding to or changing existing policy.

4.1. Policy Rules

The default for action without a specific allow rule on an SELinux system is to deny it. Therefore, any action that the system should be allowed to perform must have a corresponding rule in the security policy or it will be denied.

4.1.1. type

The type statement is used to declare a security type for specified files. Attributes for the file type can also be indicated, for example, adding the attribute sysadmfile to a type statement declares that file type to be a system administration file, which is allowed to be edited by processes running in the sysadm_t domain.

4.1.2. allow

The allow rule allows a specified access and makes no log entry of the operation. This is by far the most common rule in the SELinux policy.

4.1.3. auditallow

The auditallow rule, despite its name, does not allow the specified operation, but will log the attempt. To allow an operation while logging it, you must have both an allow and an auditallow for the specified operation.

4.1.4. dontaudit

The dontaudit rule is used for those actions that the policy author wants to be denied, but not logged. Some applications attempt actions that they do not require for proper operation, and the policy will disallow these but not clutter the log with the unimportant denial if a dontaudit rule is used.

4.1.5. neverallow

neverallow exists to ensure that certain operations are never allowed by the policy, even if specifically allowed by an allow rule elsewhere within the policy source.