PolicyStatements

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:

1. 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.
2. 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 (;). The examples below show these in detail.

The statement is valid in:

Monolithic Policy	Base Policy	Module Policy
No	Yes - But only if proceeded by the optional Statement.	Yes
Conditional Policy (if) Statement	optional Statement	require Statement
Yes - But only if proceeded by the optional Statement.	Yes	No

Examples:

# A series of require statements showing various entries:

require {
      role system_r;
      class security { compute_av compute_create compute_member check_context load_policy 
         compute_relabel compute_user  setenforce setbool setsecparam setcheckreqprot };
      class capability2 { mac_override mac_admin };
}

#
require {
     attribute direct_run_init, direct_init, direct_init_entry;
     type initrc_t;
     role system_r;
     attribute daemon;
}

#
require {
     type nscd_t, nscd_var_run_t;
     class nscd { getserv getpwd getgrp gethost shmempwd shmemgrp 
     shmemhost shmemserv };
}

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 !!.
else	An optional else keyword.
rule_list	As the rule_list above.

The statement is valid in:

Monolithic Policy	Base Policy	Module Policy
No	Yes	Yes
Conditional Policy (if) Statement	optional Statement	require Statement
Yes	Yes	Yes

Examples:

# Use of ''optional'' block in a base policy source file.

optional {
     require {
          type unconfined_t;
     } # end require

     allow acct_t unconfined_t:fd use;

} # end optional

# Use of ''optional'' / ''else'' blocks in a base policy source file.

optional {
     require {
          type ping_t, ping_exec_t;
     } # end require

     allow dhcpc_t ping_exec_t:file { getattr read execute };
     .....

     require {
          type netutils_t, netutils_exec_t;
     } # end require

     allow dhcpc_t netutils_exec_t:file { getattr read execute };
     .....
     type_transition dhcpc_t netutils_exec_t:process netutils_t;
     ...

} else {

     allow dhcpc_t self:capability setuid;
     .....
} # end optional

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:

/etc/selinux/<policy_name>/modules/active/modules/permissive_unconfined_t.pp