Section 10.6. Initial Security Identifiers

10.6. Initial Security Identifiers

A special kind of default labeling behavior is provided by initial SIDs. Initial SIDs are used in two circumstances: early in system initialization before the policy is loaded, and when an object would otherwise have an invalid or missing security context (that is, as a failsafe label).

Chapter 7 introduced SIDs, which are opaque references to security contexts used internally by SELinux. Initial SIDs are a set of reserved SIDs used during system initialization or for predefined objects. Unlike most SIDs, which are created on demand at runtime when a security context is used for the first time, initial SIDs are always present in the system. (That is, they are hard-coded in the SELinux LSM module.) Table 10-4 lists the initial SIDs used in a FC4 system.

Table 10-4. Example Initial SIDs in FC4

Initial SID	Description
kernel	Applied to all objects created by the kernel (for example, threads and sockets created by the kernel), the system object instance, and is used as a default for kernel resources.
security	Applied to the security object instance.
unlabeled	Applied to all objects with an invalid security context.
file	Default security context for file-related objects that do not otherwise have a security context. This is for file-related objects without security contexts; file-related objects with invalid security contexts receive the unlabeled SID.
port	Default security context for socket objects associated with ports that do not have a matching port security context statement.
netif	Default security context for netif objects associated with network interfaces that do not have a matching network interface security context statement.
node	Default security context for node objects associated with nodes that do not have a matching node security context statement.
sysctl	Default security context for proc filesystem system objects. These objects are normally labeled via generalized filesystem security context statements rather than via this initial SID.

Some objects are labeled via an initial SID early in system initialization, even before the policy is loaded. This labeling behavior is needed, for example, to label objects such as the kernel security server and the root filesystem, which are present in the system before the first policy load. When the policy is eventually loaded, the initial SIDs are then associated with the appropriate security context.

Initial SIDs are also used to prevent objects from having a missing or invalid security context, which would make it impossible for SELinux to correctly enforce access. Instead, SELinux associates these objects with the special unlabeled initial SID. The unlabeled initial SID should have a security context that allows only limited access, thereby preventing inappropriate access until the objects can be relabeled by the administrator or destroyed.

Invalid security contexts most commonly result from loading a new policy that removes users, roles, or types, or changes role or type authorizations. In this situation, the SIDs representing security contexts that use these invalid names or associations will become invalid and are mapped to the unlabeled SID at policy load. Invalid security contexts can also arise when transferring object instances between systems (for example, using removable media). Further, if the objects are created on a non-SELinux system, they will have no associated security context. Regardless of whether the security context is invalid or missing, SELinux will use the unlabeled initial SID on first access to the object as the security context.

Like object classes, initial SIDs are defined by the kernel and other object managers in addition to being declared in the policy. The initial SID declaration statement declares an initial SID for use in the policy. We will not normally change initial SID statements as a part of policy writing. To illustrate the syntax, consider the following statement:

sid kernel

This statement declares the initial SID kernel. This statement does nothing more than reserve the name. Initial SID names are in their own namespace and can overlap with type, object class, or other policy component names. The full syntax for the initial SID statement is in the sidebar on page 232.

Initial SID Declaration Statement Syntax (sid)

The initial SID statement (sid) reserves a name for an initial SID. Initial SIDs are defined by the kernel and other object managers; this statement makes them available to the policy. The full syntax is as follows:

sid sid_name

sid_name

The name of the initial SID. The name may contain letters or numbers.

The initial SID declaration statement is valid only in monolithic policies and base loadable modules. They are not valid in conditional statements and nonbase loadable modules.

The initial SID security context statement associates a security context with a previously declared initial SID. For example, consider the following statement:

sid kernel    system_u:system_r:kernel_t

The statement above states that the security context for the initial SID kernel is system_u:system_r:kernel_t. As you can see, both statements have the same keyword name (sid), so be careful with the differing syntax. The effect of the initial SID security context statement is to associate the security context system_u:system_r:kernel_t with the initial SID kernel, which must be previously declared with the initial SID declaration statement. The full syntax for the initial SID security context statement is in the sidebar on page 233.

Initial SID Security Context Statement Syntax (sid)

The initial SID security context statement (sid) associates a security context with a previously declared initial SID. The full syntax is as follows:

sid sid_name context; 

sid_name	The name of a previously declared initial SID.
context	The security context to associate with this initial SID.

The initial SID security context statement is valid only in monolithic policies and base loadable modules. They are not valid in conditional statements and nonbase loadable modules.