Table 2 lists the permissions for controlling access to open file description objects. Since open file descriptions may be inherited across execve or transferred through UNIX socket IPC, SELinux labels and controls open file descriptions. An open file description is labeled with the SID of its creating process, since its state is usually treated as part of the private state of the process. It is important to distinguish between the label of an open file description and the label of the file it references. A read operation on a file changes the file offset in the open file description, so it may be necessary to prevent a process from reading a file using an open file description received or inherited from another process even though the process is allowed to directly open and read the file.
|
Permissions for controlling access to file systems are shown in Table 3. SELinux labels file systems and controls services that manipulate file systems, including calls for mounting and unmounting file systems, the statfs call and the file creation calls. SELinux controls the mounting of file systems through several permission checks. It requires that the process have mounton permission to the mount point directory and mount permission to the file system. It also requires that the mountassociate permission be granted between the root directory of the file system and the mount point directory.
SELinux binds security labels to files and directories and controls access to them. It stores a persistent labeling table in each file system that specifies the security label for each file and directory in that file system. For efficient storage, SELinux assigns an integer value referred to as a persistent SID (PSID) to each security label used by an object in a file system. The persistent labeling table is partitioned into a mapping between each PSID and its security label and a mapping between each object and its PSID. Since the table is stored in each file system, file labels are preserved if the file system is mounted at a different location or if the file system is moved to a different system.
The mapping between each PSID and its security label is implemented using regular files in a fixed subdirectory of the root directory of each file system. This mapping is loaded into memory when the file system is mounted, and is updated both in memory and on the disk when a new security label is used for an object in the file system. The mapping between each object and its PSID is implemented by storing the PSID in an unused field of the on-disk inode. Since the PSID is available in the on-disk inode, no extra overhead is incurred either to obtain the PSID when a file is accessed or to set the PSID when a file is created. Additionally, since the mapping between each object and its PSID is inode-based, changes to the file system name space do not affect the mapping.
SELinux currently only implements file labeling for the ext2 file system. However, only the binding between on-disk inodes and PSIDs is filesystem-specific, so support for other local file system types can be easily added. For NFS file systems, a single label is currently used for all files mounted from a given NFS server. A design has been developed to provide complete file labeling and controls for NFS filesystems, but this design has not yet been implemented. SELinux also implements file labeling for the special procfs and devpts file systems based on the labels of the associated process, but these special file system types do not require the use of persistent label mappings.
When an unlabeled file system is first mounted, a persistent labeling table is created for the file system, using a default label for all files obtained from the security server. Subsequently, existing files may be relabeled using new system calls. A program called setfiles is used to initially set file labels from a configuration file that specifies labels based on pathname regular expressions. This program and configuration file may also be used to reset file labels to a well-defined state. However, unless the configuration file is updated to reflect runtime changes in file labels, these changes will be lost when the program is executed. Runtime changes may occur as a result of new files being created, existing files being relabeled, or changes to the name space.
|
|
Table 4 shows the permissions defined for controlling access to files, and Table 5 shows the additional permissions defined for controlling access to directories. SELinux defines a separate permission for each file and directory service. For example, SELinux defines an append permission for files in addition to the write permission, and it defines separate add_name and remove_name permissions for directories to support append-only files and directories. SELinux also defines a reparent permission for directories that controls whether the parent directory link can be changed by a rename.
SELinux provides control over each object affected by a file or directory service. For example, in addition to checking access to the parent directory, SELinux defines permissions for controlling access to the individual file itself for operations such as stat, link, rename, unlink, and rmdir.