Section 6.3. Users and User Statements

6.3. Users and User Statements

Linux and SELinux user identifiers are distinct and are often unrelated. In SELinux, it is possible for the Linux user identifier and the SELinux user identifier of a given process to differ (for example, see the discussion of user_u that follows). The design decision for SELinux to have a distinct user identifier (rather than share that of Linux) is motivated by the desire to create an immutable SELinux user identifier. In standard Linux, the user identifier changes to reflect changes in privilege (for example, changing to root). In many cases, both the real and effective user identifiers change. This makes it difficult to track which user logged in for auditing, authentication, and other uses. Separating the Linux and SELinux user identifiers allows the Linux user identifier to change as needed without affecting SELinux.

Note

Many SELinux systems, including Red Hat Enterprise Linux version 4 (RHEL4) and Fedora Core 4 (FC4), can actually change the SELinux user identifier during a login session. In particular, the su program was modified to set the Linux and SELinux user identifier. This departure from the original design goal of an immutable SELinux user identifier was motivated by usability; it was thought that not changing the SELinux user identifier would confuse users and create a much more complicated process for adding user accounts. In addition, the Linux audit framework stores an immutable login user identifier for auditing purposes, somewhat reducing the need for the SELinux user identifier to remain constant. Fedora Core 5 (FC5) reverts to the original behavior of not allowing SELinux user identifiers to change.

6.3.1. Declaring Users and Associating Roles

The user declaration statement (user) declares a user identifier in the policy and associates it with one or more roles. The user statement is the only policy statement relating to SELinux users. The example in Figure 6-1 includes the follow user declaration:

user joe roles { user_r };

This statement declares the user joe, if it has not already been declared in the policy, and associates the role user_r with the user. Unlike role statements that may be mixed among the TE statements, user statements must come after all the type and role statements and before constraints (see Figure 3-5 in Chapter 3, "Architecture").

Similar to the association between roles and types, the user association allows a role to be present in a security context with a specified user. The full syntax for the user statement is in the sidebar on page 142.

Note that there is no user transition or user allow rule. This reflects the initial design goal of immutable users. Changes to the user identifier are controlled only by constraints, which we discuss in Chapter 9.

User Declaration Statement Syntax

The user declaration statement declares a user identifier, if it has not already been declared, and associates it with one or more roles. The full syntax for the statement is as follows:

user user_name roles role_set;

user_name	The identifier for the user. If this is the first user statement for this identifier, the user identifier is declared. The identifier can be any length and can contain ASCII characters, numbers, period, and underscore (_).
role_set	One or more role identifiers that must be previously defined in the policy. Multiple identifiers are specified using a space-separated list enclosed in braces ({})for example, { staff_r sysadm_r }.

User declarations are valid in monolithic policies, base loadable modules, and non-base loadable modules. They are not valid in conditional statements.

6.3.2. Mapping Linux Users to SELinux Users

The login programs (for example, login, sshd) are responsible for mapping Linux users to SELinux users. On login, if there is an SELinux user identifier that is exactly the same as the Linux user identifier, the matching SELinux user identifier becomes the user identifier in the security context for the initial shell process. In this way, if a Linux user identifier also exists as a user identifier in the SELinux policy, all login processes will set the initial shell process security context user identifier to that matching Linux identity.

In many cases, especially general-purpose configurations such the default policies in RHEL4 and FC4, it is not desirable to have to define each ordinary user in the policy. Ordinary users typically have the same privileges with respect to SELinux (that is, the user_r role and the user_t initial user domain type). To address this issue, SELinux has a special user identity, user_u, called the generic user. If the generic user user_u is defined in the policy, all Linux users will be mapped to it if they do not have a matching SELinux user in the policy.

For example, suppose we have the following user statement in our policy:

user user_u roles { user_r };

This statement defines the generic user user_u and authorizes it for the role user_r just as we did for joe earlier. The difference is that if user_u is defined in the policy, all Linux users that are not explicitly defined in the policy are mapped to user_u. So, for example, if jane is a Linux user identifier but there is no user jane defined in the SELinux policy, when the Linux user jane logs in, the user identifier in the initial shell process security context will be user_u. Because joe is defined in the policy, the initial SELinux user identifier for that user will be joe, even though user_u is also defined in the policy.

If the generic user user_u is not defined in the policy, any Linux user identifier not explicitly defined in the SELinux policy will be unable to log in, even in permissive mode. The reason for this is that on login the initial shell process must have a valid security context, including a user identifier. If neither user_u nor the Linux user identifier is defined in the policy, the login process cannot create a valid security context (because there is no user identifier for it to use). Therefore, if you do not include user_u in your policy (which for many configurations makes sense), you must explicitly add all Linux users to the SELinux policy.

Note

In FC5, the user-mapping mechanism is greatly enhanced to allow the explicit mapping of Linux users to SELinux users through a configuration file. This allows the creation of more than one generic user (for example, staff_u in addition to user_u). The existing mapping rules are retained as a fallback for backward compatibility. Chapter 13 includes additional information about new tools that can manage user mappings.

SELinux has a second special user, the system user system_u, which is typically used for all system processes such as init, and daemons started by init. Technically, the user system_u has no special meaning and is not treated exceptionally in any way within the policy language. However, most existing policies include this user, and systems are generally configured expecting that this SELinux user exists for system resources. It is generally a good idea to always include system_u in your policy.

Warning

Never create a Linux user account with the identifier system_u. If you do, that Linux user will be able to log in with the system user identifier, which is usually highly privileged (though still much less privileged than root on an ordinary Linux system).