Section 10.5. Miscellaneous Object Labeling


10.5. Miscellaneous Object Labeling

The labeling mechanisms for the remaining object classes (capability, process, security, and system) are listed in Table 10-3.

Table 10-3. Miscellaneous Object Classes Associated Labeling Mechanisms

Object Class

Labeling Mechanism(s)

capability

Inherited from the associated process object

process

Inherited from parent process, or set by domain transition, or dynamic context transition

security

SECURITY initial SID

system

SYSTEM initial SID


10.5.1. Capability Object Labeling

The capability object class is closely related to the process object class. Not surprisingly, capability objects have the same security context as the process with which they are associated. For example, consider the following rule:

allow user_t self : capability dac_override;


This allow rule states that processes of type user_t are allowed to retain the dac_override capability. The type of the capability object is, by virtue of the self keyword, the same as the process. There is no policy statement or mechanism for setting or changing the security context of capability objects.

10.5.2. Process Object Labeling

The labeling of process objects is central to SELinux, because it is the mechanism for associating the correct access with an application. Chapter 2 contains a lengthy description of the mechanics and concepts of domain transitions, which are the most important aspect of process labeling. Here we discuss the other aspects of process labeling.

In Linux, process objects are not created when applications are executed with the execve(2) system call. Instead, new processes are created by copying another process using fork(2) or clone(2). New process objects, therefore, inherit the security context of the creating process to reflect that they have the same security properties. There is no provision for overriding this labeling decision; both domain transitions and dynamic security context transitions, which are the only means to change the security context of a process, can change only the security context of an existing process.

A domain transition is a change of the process security context on an execve(2) system call. The security context change can happen automatically as the result of a type_transition rule or program request through the use of the setexeccon(3) library call. As always, a change of the security context for a process must be explicitly allowed by the policy.

We normally focus on changing the process type during domain transition via the execve(2) system call, but it is also possible to change the user or the role. Role changes can be automatic, through role transition statements, and both user and role changes can be program requested explicitly through setexeccon(3). Changing the user or role of a process is controlled by constraints and role allow rules, which are covered in Chapters 6 and 7.

A dynamic security context transition is program requested labeling that changes the security context of an existing process. The change, which is accomplished with the setcon(3) library call, must be allowed by the policy through the dyntransition permission. Chapter 5 has more information on dynamic security context transition, including a discussion of its dangers and our advice not to use it.

10.5.3. System and Security Object Labeling

The system and security object classes are unique in that there is only ever one instance for each. The kernel and security initial SIDs are used to label the system and security object instances, respectively. There is no mechanism for changing the security context of these objects.




SELinux by Example(c) Using Security Enhanced Linux
SELinux by Example: Using Security Enhanced Linux
ISBN: 0131963694
EAN: 2147483647
Year: 2007
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net