6.3 SELinux Policy Syntax

     

The railroad diagram in Figure 6-9 represents an overview of the syntax of an SELinux policy.

Figure 6-9. The SELinux Policy

As the figure shows, an SELinux policy consists of 11 elements, several of which are optional:

classes

Defines the security object classes recognized by SELinux.

initial_sids

Defines initial SIDs for important security objects.

access_vectors

Defines access vectors associated with each security object class.

mls

Defines MLS configuration (optional).

MLS is not currently implemented in sample SELinux policies and is not covered in this book.

te_rbac

Defines type enforcement and role-based access control configuration.

users

Defines the user configuration.

constraints

Defines constraints that the security policy must observe (optional).

initial_sid_contexts

Defines the security contexts of important security objects.

fs_use

Defines the method of labeling of filesystem inodes.

genfs_contexts

Defines security contexts for filesystems lacking persistent labels (optional).

net_contexts

Defines security contexts for network objects.

The policy elements must appear in the order indicated by the railroad diagram. However, you generally don't have to concern yourself with the order of policy statements, because each type of statement resides in a designated file or directory. As explained in Chapter 4, the SELinux policy Makefile assembles these files into a single file before compiling the policy source statements. The Makefile ensures that policy statements are presented to the policy compiler in the proper order. Table 6-1 shows the correspondence between the policy elements and files in the src/policy SELinux source tree.

Table 6-1. Policy elements and associated files

Element	File or directory (relative to src/policy )
classes	flask /security_classes
initial_sids	initial_sid_contexts
access_vectors	flask/acess_vectors
opt_mls	mls
te_rbac	rbac *.te domains/*.te domains/misc/*.te domains/programs/*.te macros/*.te macros/program/*.te types/*.te
users	users serviceusers (Fedora Core)
opt_constraints	constraints
initial_sid_contexts	flask/initial_sids
fs_uses	fs_use
opt_genfs_contexts	genfs_contexts
net_contexts	net_contexts

Table 6-1 shows files and directories used in the Fedora Core 2 SELinux implementation. The files may have different contents or locations under other implementations of SELinux.

One of the most important policy elements, te_rbac , contains type enforcement and role-based access control declarations. Along with the file context configuration, the TE and RBAC configuration is the part of an SELinux policy that is most often modified. Syntactically, the te_rbac element consists of a series that freely intermingles two subelements ” te_decl and rbac_decl ”as shown in Figure 6-10.

Figure 6-10. TE and RBAC declarations (te_rbac)

6.3.1 Basic Policy Elements

Before presenting the syntax of the SELinux user and role-based access control declarations, let's look at a few subelements that appear in a variety of SELinux policy elements and at a few principles that govern their use. Figure 6-11 shows the syntax of a subelement known as identifier_list . As its name suggests, the subelement represents a list of identifiers. An example of such a list appears in the following declaration from the ping.te file:

 allow ping_t self:rawip_socket { create ioctl read write bind    getopt setopt }; 

The curly braces enclose an identifier list specifying the permissions related to a raw IP socket: create , ioctl , read , write , bind , getopt , and setopt .

Figure 6-11. The identifier_list subelement

Notice that the identifiers are separated from one another by white space. Another subelement, id_comma_list , specifies a comma-separated list of identifiers. A railroad diagram for this subelement appears as Figure 6-12.

Figure 6-12. The id_comma_list subelement

Another statement of the ping.te file provides an example of this subelement:

 type ping_exec_t, file_type, sysadmfile, exec_type; 

In this statement, the identifiers ping_exec_t , file_type , sysadmfile , and exec_type appear as an id_comma_list .

Let's now consider some fine points of railroad diagrams. Literals do not need railroad diagrams to explain them, because they are labeled with the values they match. Though literals sometimes appear in railroad diagrams in uppercase form, the strings they represent can appear in the SELinux policy in either uppercase or lowercase. So, with reference to Figure 6-11, you can anticipate that most identifiers will appear in lowercase rather than uppercase. That is, you should expect the following:

 create, ioctl, read, write, bind, getopt, setopt 

rather than:

 create, ioctl, read, write, bind, getopt, setopt 

However, it's entirely permissible to specify uppercase identifiers. It's just that SELinux policy developers generally prefer not to do so. What matters is consistency. The identifiers create and CREATE are both legal but also entirely distinct, because one uses lowercase letters whereas the other uses uppercase letters .

Let's consider one more common policy subelement, known as names , which appears in Figure 6-13. This element can represent such strings as:

• A single identifier

• A list of identifiers separated from one another by white space, enclosed within curly braces

• An asterisk (*)

• An identifier preceded by a tilde (~)

• A list of identifiers separated from one another by white space and enclosed within curly braces, and preceded by a tilde (~)

• Two identifiers separated by a hyphen (-)

Figure 6-13. The names subelement and related subelements

Some rather bizarre extensions are also permissible. For instance, the following is a valid nested_id_set subelement:

 { x -y { a b c } } 

You may be curious about the meaning or use of this subelement. But, for the moment, please focus merely on the syntax, not the meaning. The meaning of the subelement emerges from the context in which it is used. So rather than continue to examine subelements ”a process that could be continued indefinitely ”let's start looking at concrete examples by considering the users element, which is used to describe user declarations.