The files in $SELINUX_SRC/file_contexts/ declare the security
contexts that are applied to files when the policy is installed.
You can read more about what a file context is at Section 2.4 File System Security
Contexts.
The file context descriptions use regular expression pattern
matching (regexp) to match a file, set of
files, directory, or directory and associated files. A specific
SELinux label is then applied to that:
# Syntax of file context description
regexp <-type> ( <file_label> | <<none>> )
|
The regexp is anchored on both ends, meaning the expression
search only considers matches that start with the first character
and end with the last character. This means that it ignores an
expression that appears in the middle of a sentence, the way
/var/run appears in this sentence, and
only declares a match if the pattern is on a line by itself:
This is the way a directory is displayed by the output of
ls, and is how setfiles sees files and directories when it
traverses the directory tree. In regexp notation, this kind of
match is denoted by prepending a ^ (caret) symbol
and appending a $ (dollar sign
or ding) to the expression. This is done
automatically by SELinux, and can be overridden using the
match-anything pattern .* on
either or both sides of the regexp pattern.
The field -type is optional
and can be left blank. When it is filled, it is similar to the mode
field for the ls command. For example, the
-d means to match only
directories, the -- means to
match only files.
The value field is the last field on the right, and is set to
either a single security label such as system_u:object_r:home_root_t or is set to
<<none>>. The <<none>> value tells the
relabeling application to not relabel the matching file. In the
case where there is more than one match, the last matching value is
used. Hard linked files that have different contexts generate a
labeling error, and the file is labeled based on the last matching
specification other than <<none>>.
There are files listed in types.fc
that are not persistent, but get created each time during boot.
Those files gain their labels through type transition rules, but
they are listed here to prevent their label being overwritten by a
relabeling operation during runtime. One example of this is
/var/run/utmp.
Here are some examples from $SELINUX_SRC/file_contexts/types.fc, the main file
describing file contexts:
/bin(/.*)? system_u:object_r:bin_t
/bin/bash -- system_u:object_r:shell_exec_t
/u?dev(/.*)? system_u:object_r:device_t
/u?dev/pts(/.*)? <<none>>
ifdef(`distro_redhat', `
/dev/root -b system_u:object_r:fixed_disk_device_t
')
/proc(/.*)? <<none>>
/sys(/.*)? <<none>>
/selinux(/.*)? <<none>>
/etc(/.*)? system_u:object_r:etc_t
/etc/passwd\.lock -- system_u:object_r:shadow_t
/etc/group\.lock -- system_u:object_r:shadow_t
/etc/shadow.* -- system_u:object_r:shadow_t
/usr(/.*)?/lib(64)?/.*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
/usr(/.*)?/java/.*\.so(\.[^/]*)* -- system_u:object_r:shlib_t
|
Similarly, there are specific file contexts files for all
domains, depending on their special needs. The *.fc files are present in the policy source, but
are only used if there is an associated *.te file in $SELINUX_SRC/domains/program/. Here is an example
from mta.fc:
ifdef(`dhcp_defined', `', `
/var/lib/dhcp(3)? -d system_u:object_r:dhcp_state_t
define(`dhcp_defined')
')
|
Example 3-1. ifdef
statement in a context file
Another interesting example is Example
3-1. The file context dhcp_state_t must be set for the DHCP-based
daemons to work properly, so the pattern and value are in both
dhcpd.fc and dhcpc.fc (the DHCP client daemon contexts). This is
to ensure the label value is present in case one file is not
included in a policy build. In fact, this is the case for the
targeted policy, where the DHCP client is not confined by SELinux
policy. In this case, the file dhcpd.fc
declares the file context for /var/lib/dhcp for the pattern matching ^/var/lib/dhcp(3)?$.
If you include policy to cover the DHCP client programs, you
want to ensure that it also can declare the context for /var/lib/dhcp/. However, if you include both
programs and they both declare the context, setfiles reports an error during policy build. This
happens when a file context is specified multiple times, even if
the specification is identical.
To handle this, a conditional ifdef statement is used. When concatenating
the file context files into the single file $SELINUX_SRC/file_contexts/file_contexts, the first
time the ifdef statement is
reached, the definition dhcp_defined is checked for. If it is
defined, the value true is
returned, and the additional file context is skipped. If
dhcp_defined has not been
defined, the value returns as false, the file context is read from inside
the statement, and dhcp_defined
is defined.
