Table 3 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 is distinct from the file execute permission which is used to control the ability of a process to initiate the execution of a program. Since Linux on the x86 does not support read without execute permissions on memory pages, the best degree of control that can be obtained in secure Linux will be from the process execute permission check that is done. The implication of this is that it will be possible for a process to be tricked into executing memory that was written as data. This problem would not be present on other architectures that do not have this limitation.
The transition permission is used to control the ability of a process to transition from one 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, will be 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. Additional potential controls for scheduling, sessions, process groups, and capabilities are discussed in Section 10.
Currently, a separate permission for each Linux capability is defined for the capability object class. This allows control over all of the abstractions for which capabilities are currently defined. In the future, the control points for each capability will require reexamination to determine if the capability permission is sufficient to control the resource.