The SELinux policy language includes several declaration types that establish contexts for various objects:
Objects having initial SIDs
Filesystems supporting persistent labels
Filesystems not supporting persistent labels
Network-related objects
Some filesystems, such as ext2 and ext3, provide space in which SELinux can store persistent file labels. However, some filesystems do not have this capability. So that even uncooperative filesystems can be used with SELinux, SELinux lets you specify static labels that are applied to files within such filesystems.
The following subsections describe these declarations.
Figure 8-6 shows the syntax of initial SID context declarations, which are used to specify the security context of objects having initial SIDs.
The example SELinux policy typically includes a bit more than two dozen initial SID declarations. A typical declaration is:
sid kernel system_u:system_r:kernel_t
This declaration assigns the security context
system_u:system_r:kernel_t
to the
kernel
object. In general, it’s
not possible to change or add an initial SID declaration without
making corresponding changes to SELinux itself, so changes and
additions are generally made only by SELinux developers rather than
system administrators.
When an SELinux system mounts a filesystem, SELinux must determine whether the filesystem supports persistent labels. If so, SELinux processes the persistent labels according to the options specified in three types of declaration:
Figure 8-7 shows the syntax for all three types of declarations.
The identifier
appearing in the syntax diagram
denotes the filesystem type. Typical values include the following:
Some typical filesystem labeling declarations appearing in sample policies include:
fs_use_xattr ext2 system_u:object_r:fs_t; fs_use_xattr ext3 system_u:object_r:fs_t; fs_use_xattr xfs system_u:object_r:fs_t; fs_use_task pipefs system_u:object_r:fs_t; fs_use_task sockfs system_u:object_r:fs_t; fs_use_trans devpts system_u:object_r:devpts_t; fs_use_trans tmpfs system_u:object_r:tmpfs_t; fs_use_trans shm system_u:object_r:tmpfs_t;
Thus, ext2
, ext3
, and
xfs
filesystems store file labels in their
extended attribute space (fs_use_xattr
);
pipefs
and sockfs
filesystems
use the special facility for pipe and socket pseudofilesystems
(fs_use_task
); and devpts
,
tmpfs
, and shm
filesystems use
the special facility for pseudoterminal, memory-resident, and
shared-memory filesystems (fs_use_trans
).
For filesystems
not
supporting persistent labels, SELinux behavior
can be specified using Genfs
declarations. Figure 8-8 shows the syntax of such declarations, which
resembles the syntax used in FC (file context) files, with two
differences:
The replaceable text path
gives the mount
point of the filesystem. More precisely, it gives a prefix for the
mount point, since any directory below the specified directory is
considered to match the declaration. Specifying
/nfs
matches any filesystem mounted at
/nfs
or any subdirectory of
/nfs
, and specifying / matches any mounted
filesystem. When multiple declarations match an actual mount point,
the longest matching declaration is used, and the others are ignored.
The optional identifier, which is preceded by a hyphen (-), also can be used to restrict the type of files to which the declaration applies. File types are specified using the codes displayed by the ls command; for instance, use -c to specify that the declaration applies only to character device files, or use -b to specify that the declaration applies only to block device files.
Genfs
declarations reside in the
genfs_contexts
file,
which contains about three dozen declarations in the example SELinux
policy. These declarations assign security contexts to filesystems
having types such as the following:
autofs
|
bdev
|
cifs
|
cramfs
|
eventpollfs
|
fat
|
futexfs
|
iso9660
|
msdos
|
nfs
|
nfsd
|
ntfs
|
proc
|
ramfs
|
romfs
|
rootfs
|
rpc_pipefs
|
selinuxfs
|
smbfs
|
sysfs
|
usbdevfs
|
usbfs
|
vfat
|
For example, a typical declaration assigning a security context to
files residing on an nfs
filesystem mounted
somewhere below the root (/) directory is:
genfscon nfs / system_u:object_r:nfs_t
The related type nfs_t
is defined in the file
types/nfs.te
. The proc
filesystem receives special attention in the
genfs_contexts
file. Over one dozen of the entries
in the file pertain to that filesystem.
Recent releases of SELinux support labeling of
network objects, including ports, network interfaces, hosts (nodes),
and received packets. This is useful in implementing the
principle of least privilege, by
restricting users and processes from unnecessarily accessing network
objects. The labeling is specified by network declarations residing
in the file net_contexts
. Figure 8-9 shows the related syntax, which includes three
declaration types:
Specifies the security context of a port.
Specifies the security context of a network interface and the security context of packets it received.
Specifies the security context of a host (node).
Portcon
declarations specify security contexts of
local ports. Here is a typical portcon
declaration:
portcon tcp 80 system_u:object_r:http_port_t
The declaration assigns the security context
system_u:object_r:http_port_t
to port TCP/80. The
related type http_port_t
is defined in the file
domains/program/apache.te
by the declaration
type http_port_t, port_type;
An access-vector rule such as the following can restrict access to the port:
allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind;
This rule allows only the httpd_t
domain to
perform the name_bind
operation on port TCP/80;
thus, other domains are prohibited from binding to the port.
Netifcon declarations specify
security contexts of network
interfaces. Here is a typical netifcon
declaration:
netifcon eth0 system_u:object_r:netif_eth0_t system_u:object_r:netmsg_eth0_t
Notice that the declaration specifies two security contexts. The
first security context pertains to the network interface itself,
eth0
. The second security context pertains to
packets received on the network interface.
An access vector rule such as the following can restrict access to the network interface or packets received on it:
allow vmware_t netif_eth0_t:netif rawip_send;
This rule allows the vmware_t
domain to send raw
IP traffic with the eth0
interface.
Nodecon
declarations specify security contexts of hosts. Here is
a typical nodecon
declaration:
nodecon 127.0.0.1 255.0.0.0 system_u:object_r:node_lo_t
This declaration binds the security context
system_u:object_r:node_lo_t
to hosts having IP
addresses 127.0.0.1 and netmask 255.0.0.0—that is, the local or
loopback host.