Contents

Policy Support Statements

This section contains language statements used to support policy.

module Statement

This statement is mandatory for loadable modules (non-base) and must be the first line of any module policy source file. The identifier should not conflict with other module names within the overall policy, otherwise it will over-write an existing module when loaded via the semodule command. The semodule -l command can be used to list all active modules within the policy.

The statement definition is:

module module_name version_number;

Where:

module

The module keyword.

module_name

The module name.

version_number

The module version number in M.m.m format (where M = major version number and m = minor version numbers).

The statement is valid in:

Monolithic Policy

Base Policy

Module Policy

No

No

Yes

Conditional Policy (if) Statement

optional Statement

require Statement

No

No

No

Example:

# Using the ''module'' statement to define a loadable module called
# ''bind'' with a version ''1.0.0'':
module bind 1.8.0;

require Statement

The require statement is used for two reasons:

Within loadable module policy source files to indicate what policy components are required from an external source file (i.e. they are not explicitly defined in this module but elsewhere). The examples below show the usage.

Within a base policy source file, but only if preceded by the optional Statement to indicate what policy components are required from an external source file (i.e. they are not explicitly defined in the base policy but elsewhere). The examples below show the usage.

The statement definition is:

require { rule_list }

Where:

require

The require keyword.

require_list

One or more specific statement keywords with their required identifiers in a semi-colon (;) separated list enclosed within braces ({}).

The valid statement keywords are:

role, type, attribute, user, bool, sensitivity and category. The keyword is followed by one or more identifiers in a comma (,) separated list, with the last entry being terminated with a semi-colon (;).

class. The class keyword is followed by a single object class identifier and one or more permissions. Multiple permissions consist of a space separated list enclosed within braces ({}). The list is then terminated with a semi-colon (;).

optional Statement

The optional statement is used to indicate what policy statements may or may not be present in the final compiled policy. The statements will be included in the policy only if all statements within the optional { rule list } can be expanded successfully, this is generally achieved by using a require Statement at the start of the list.

The statement definition is:

optional { rule_list }

Or

optional { rule_list } else { rule_list }

Where:

optional

The optional keyword.

rule_list

One or more statements enclosed within braces ({}). The list of valid statements is given in a list I have somewhere !!.

policycap Statement

Policy database version 22 introduced the policycap statement to allow new capabilities to be enabled or disabled via the policy. In Fedora 10 there are two policy capabilities configured as shown in the SELinux Filesystem section, and are network_peer_controls and open_perms.

The statement definition is:

policycap capability;

Where:

policycap

The policycap keyword.

capability

The capability identifier that needs to be enabled for this policy.

The statement is valid in:

Monolithic Policy

Base Policy

Module Policy

Yes

Yes

No

Conditional Policy (if) Statement

optional Statement

require Statement

No

No

No

Example:

# This statement enables the network_peer_controls to be enabled
# for use by the policy.
#
policycap network_peer_controls;

permissive Statement

Policy database version 23 introduced the permissive statement to allow the named domain to run in permissive mode instead of running all SELinux domains in permissive mode (that was the only option prior to version 23). Note that the permissive statement:

Only tests the source context for any policy denial.

Can be set by the semanage command as it supports a permissive option as follows:

semanage supports enabling and disabling of permissive

mode using the following command:

# semanage permissive -a|d type
# This example will add a new module in /etc/selinux/
# <policy_name>/modules/active/modules/ called
# permissive_unconfined_t.pp and then reload the policy:
semanage permissive -a unconfined_t

Can be built into a loadable policy module so that permissive mode can be easily enabled or disabled by adding or removing the module. An example module is as follows:

# This is an example loadable module that would allow the
# domain to be set to permissive mode.
#
module permissive_unconfined_t 1.0.0;
require {
type unconfined_t;
}
permissive unconfined_t;

The statement definition is:

permissive type_id;

Where:

permissive

The permissive keyword.

type_id

The type identifier of the domain that will be run in permissive mode.

The statement is valid in:

Monolithic Policy

Base Policy

Module Policy

Yes

Yes

Yes

Conditional Policy (if) Statement

optional Statement

require Statement

No

Yes

No

Example:

<nowii># This is the simple statement that would allow permissive mode</nowiki>
# to be set on the httpd_t domain, however this statement is
# generally built into a loadable policy module so that the
# permissive mode can be easily removed by removing the module.
#
permissive httpd_t;

semanage(8) Command example:

semanage permissive -a unconfined_t

This command will produce the following module in the default <policy_name> policy store and then activate the policy: