Table 1 shows the permissions defined for the process management component. The process execute permission is used to control the ability of a process to execute from a given executable image. This permission is checked between the label of the transformed process and the label of the executable on every program execution. It is also checked when an ELF or script interpreter is executed, and when a file is memory-mapped with execute access (i.e. a shared library). This process execute permission is distinct from the file execute permission which is used to control the ability of a process to initiate the execution of a program.
The transition permission is used to control the ability of a process to transition from one security identifier (SID) to another. The entrypoint permission is used to control what programs may be used as the entry point for a given process SID. This permission is similar to the process execute permission, except that it is only checked when a process transitions to a new SID. Hence, the security policy can distinguish between what programs may be used to initially enter a given process SID and the full set of programs that may be executed by that process SID.
This entrypoint permission is especially necessary in an environment with shared libraries, since most processes must be authorized to execute the system dynamic loader. Without separate control over entry point programs, any security label could be entered by executing the system dynamic loader. Separate entry point control is also necessary in order to support security label transitions on scripts, since the new security label must be authorized to execute the interpreter and the script.
Separate permissions for each signal could easily be defined, but until empirical evidence suggests this is necessary, this will not be done. Separate permissions were defined for the SIGKILL and SIGSTOP signals, sigkill, sigstop respectively, since these signals cannot be caught or ignored. A separate permission, sigchld was also defined to control the SIGCHLD signal because experience demonstrated that it was useful to control this signal separately. A single permission, signal, is used to control the remaining signals.
The ptrace permission is used to control the ability of a process to trace another process. The getsched, setsched, getsession, getpgid, setpgid, getcap, and setcap permissions are used to control the ability of a process to observe or modify the corresponding attributes of another process.
In addition to the permissions listed in this table, SELinux provides an equivalent permission for each Linux capability. This allows the security policy to control the use of capabilities based on the SID of the process. SELinux could also be extended to provide a finer-grained replacement mechanism for capabilities. Such a mechanism was developed for one of SELinux's predecessors, the DTOS system [20]. This mechanism permitted privileges to be granted based on both the attributes of the process and the attributes of the relevant object, e.g. discretionary read override could be granted to a particular set of files. Since the mechanism obtained privilege decisions from the security server, management of privileges was centralized and verification that privileges were granted appropriately was straightforward.