8.2 Other Context- Related Declarations 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. 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 
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. 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 
The identifier 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; 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 ). 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: Figure 8-8. Genfs declaration 
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. 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_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. 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_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. 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_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.  | 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. | |
| 