8.2 Other Context-Related Declarations
The SELinux policy language includes several
declaration types that establish contexts for various objects:Objects having initial SIDsFilesystems supporting persistent labelsFilesystems not supporting persistent labelsNetwork-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.
8.2.1 Syntax of Initial SID Context 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.
Figure 8-6. Initial SID context declaration

dozen initial SID declarations. A typical declaration is:
sid kernel system_u:system_r:kernel_tThis 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.
8.2.2 Syntax of Filesystem Labeling Declarations
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:fs_use_xattr
Specifies options for conventional
filesystems.
fs_use_task
Specifies options for
pseudofilesystems associated with pipe and socket objects.
fs_use_trans
Specifies options for
pseudofilesystems associated with RAM disk devices, pseudoterminals,
and shared memory objects.
Figure 8-7 shows the syntax for all three types of
declarations.
Figure 8-7. Filesystem labeling declaration

appearing in the syntax diagram
denotes the filesystem type. Typical values include the following:devpts
Pseudoterminal filesystem
ext2
Linux Ext2 filesystem
ext3
Linux Ext3 filesystem
pipefs
Pseudofilesystem associated with a pipe
shm
Pseudofilesystem associated with a
shared memory object
sockfs
Pseudofilesystem associated with a
socket
tmpfs
Pseudofilesystem associated with a
memory-resident filesystem
xfs
Linux Xfs filesystem
Some typical filesystem labeling declarations appearing in sample
policies include:
fs_use_xattr ext2 system_u:object_r:fs_t;Thus, ext2
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;
, 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
).
8.2.3 Syntax of Genfs Declarations
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 declaration begins with the keyword genfscon
.The genfscon
keyword is
followed by an identifier
giving the filesystem
type.
Figure 8-8. Genfs declaration

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_tThe 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.
8.2.4 Syntax of Network Declarations
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:portcon
Specifies the security context of a port.
netifcon
Specifies the security context of a network interface and the
security context of packets it received.
nodecon
Specifies the security context of a host (node).
Figure 8-9. Network declaration

8.2.4.1 Portcon declarations
Portcon
declarations specify security contexts of
local ports. Here is a typical portcon
declaration:
portcon tcp 80 system_u:object_r:http_port_tThe 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.
8.2.4.2 Netifcon declarations
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_tNotice 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.
8.2.4.3 Nodecon declarations
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_tThis 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.0that is, the local or
loopback host.

The sample policy related to nodecon
declarations
is relatively immature. For instance, the policy distributed with
Fedora Core 2 includes no access vector rules related to types bound
to
hosts
by
nodecon
declarations.