Section 10.1. Introduction to Object Labeling

10.1. Introduction to Object Labeling

All objects in SELinux have an associated security context from the time they are created until they are destroyed. This property is central to the ability of SELinux to enforce access control. For example, let's look at the security context of a file we first discussed in Chapter 2, "Concepts:"

# ls -Z /etc/shadow -r-------  root   root  system_u:object_r:shadow_t  shadow

This example demonstrates the program ls displaying the security context for the file /etc/shadow. The security context associated with an object, in this case system_u:object_r:shadow_t, is the only attribute SELinux uses in access control decisions. Therefore, it is fundamentally important that this and all objects have the correct security context assigned to them.

Until this point, we have generally discussed objects with the assumption that they have a security context, with little or no mention of how that security context was determined and applied. This reflects the goal that labeling should not be a normal concern when using an SELinux system. Users and administrators can use SELinux systems in much the same way they use standard Linux systems without having to be concerned with security contexts. In addition, this goal allows nearly all programs to run unmodified on SELinux.

The SELinux policy language includes features, such as type_transition rules for file and domain transitions, that make labeling decisions automatic and largely transparent. However, sometimes, like during system administration, policy development, and system installation, labeling becomes an issue with which we need to concern ourselves. As policy writers, we must carefully craft labeling policy statements to ease label management at runtime.

An object is labeled on an SELinux system in four basic ways:

• Policy statements The SELinux policy language includes features, such as type_transition rules, that specify behavior for object labeling decisions.

• Hard-coded defaults Most object classes have some type of default labeling behavior encoded within the object managers. For example, by default when a process creates a new socket, the new socket has the same security context as its creating process.

• Program-requested labeling For some object classes, SELinux provides a variety of application programming interfaces (APIs) that allow programs to explicitly request a label, both for new and existing object instances. For file-related objects that are stored on filesystems that support labeling, these APIs are used by SELinux utilities that initialize and repair file labels (for example, by the rpm package manager when installing the system).

• Initial SIDs SELinux has a set of initial security identifiers (initial SIDs) used to label a few objects and as a failsafe label when an object would otherwise have a missing or invalid label.

For many objects, a combination of all these behavior types may be used to determine the label of a new object. Labeling decisions also use information from the execution environment (for example, the security context for the process and related object instances) to compute a security context for new objects. In all cases, the policy must allow the appropriate access for the labeling to occur. Object labeling behavior usually controls only how object labeling is attempted and not whether it is allowed.

We have already discussed some of the policy rules (that is, type and role transition rules) that support labeling decisions in Chapter 2, Chapter 5, "Type Enforcement," and Chapter 6, "Roles and Users." In this chapter, we discuss additional policy statements for labeling network-related object classes. As you will see, these statements are object class-specific and do not apply to all object classes.

The default labeling behaviors for each object class are hard-coded into the object managers that implement the classes. These defaults are used in the absence of relevant policy labeling rules and for those object classes that have no associated policy labeling rules. The default for most object classes is to inherit the security context of the creating process and/or containing object. For example, file-related objects inherit the type of the containing directory, a hard-coded role (object_r), and the SELinux user of the creating process.

In the remainder of this chapter, we discuss the many ways that a policy writer must address object labeling.