Kernel Korner - NSA Security Enhanced Linux

With fine-grained mandatory access controls in your system, you can even put limits on what root can do.
Frequently Used Terms

When reading documents on SE Linux or mailing list posts, the following terms always are used. It is important to familiarize yourself with them as much as possible before you attempt to install SE Linux. Doing so makes things much easier later on.

Domain: a domain details what processes can and cannot do or, rather, what actions a process can perform on various types. If you are in the user_t domain (the standard unprivileged user domain) and you run the command ps aux, you see only the processes running in the user_t domain. Some examples of domains are sysadm_t, the system administration domain, and init_t, the domain in which init runs. The domain in which the passwd program is run by an unprivileged user is passwd_t.

Role: a role determines what domains can be used. The domains that a user role can access are predefined in the policy database. If a role is not authorized to enter a domain (in the config files), it is denied. Some examples of roles are the general unprivileged user role (user_r) and the system administrator role (sysadm_r).

Consider the following example: in order for a user from the user_t domain to execute the passwd command, role user_r types passwd_t ; is specified in the relevant config file. In addition, other domain transitioning rules must be set that are not covered here. This added code states that a user in the user role (user_r) is allowed to enter the passwd_t domain, so he can run the passwd command. Another consideration is whether the old domain is allowed to transition to the new domain.

Now that we have defined domains and roles, we can look at comparisons between SE Linux and the standard UNIX uid (user ID). If root owns a program with UNIX permissions 4777 (making the program setuid root), any user on the system can execute that program, resulting in a security issue. With SE Linux, however, if a process triggers a domain transition to a privileged domain and the role of the process is not authorized to enter a particular domain, the program cannot be run. Every process on an SE Linux system runs in a domain that determines what access rights a process possesses.

Identity: an identity under SE Linux is not the same as the traditional UNIX uid with which most readers might be familiar. Identities under SE Linux form part of a security context that controls what you can and cannot do. An SE Linux identity and a regular UNIX login name may have the same textual representation (and in most cases they do for ease of use), but it is important to understand that they are two different beings. The default is to have them be the same, if the SE Linux identity in question exists. Therefore, if I log in as user faye on an SE Linux system, and if the policy database has the identity faye compiled into it, then my processes would be assigned to the faye identity.

To illustrate that standard UNIX user IDs are different from SE Linux identities, consider the su command. Running su does not change the user identity under SE Linux, but it does change the uid in the same way it would on a non-SE Linux system. If user faye, on the SE Linux system, types su - to switch to root and then runs the id command, which returns her security context and other information, she would see that her identity still is faye and not root, but her uid has changed. To illustrate this further, if an unprivileged user with the login name faye runs the id command, she would see the security context of:

uid=1000(faye) gid=1000(faye)
groups=1000(faye) context=faye:user_r:user_t
sid=45

The identity portion of the security context in this case is faye. Notice the uid of 1000. Next, say faye does an su to root and runs the id command again; she now would see:

uid=0(root) gid=0(root) groups=0(root)
context=faye:user_r:user_t sid=453

The identity has not changed to root as might be expected, but the uid has changed to 0. However, if user faye has been granted access to enter the superuser role, or sysadm_r, she can do so by either logging in at the console and specifying she wants the superuser role or entering the newrole -r command covered later. If she then runs the id command again, she now sees context=3Dfaye:sysadm_r:sysadm_t.

So again, the identity remains the same, but the role and domain (second and third fields, respectively) have changed. Maintaining the identity in this manner is useful where user accountability is required. It also is crucial to system security because the user identity determines what roles and domains can be used. With regular UNIX, if you have a setuid or setgid program that is not world-executable, whether it is executed is determined not by the permissions of the user you are logged in as, but by the user you last did an su to reach. This restriction does not exist under SE Linux, as your identity is tracked throughout all operations. If your domain has not been granted the access to execute that setuid/setgid program, you cannot run it even if you did an su to root. The domains you are permitted to enter are determined by your role, and the roles you are permitted to enter are determined by your identity. Thus, identity indirectly controls the list of domains you may enter.

Type: each object has a type assigned to it, and that type determines what can access the object. Objects here are files, directories, sockets and other processes. A type is similar in concept to a domain, the difference being that a domain applies only to processes. More specifically, a domain is a type that can be applied to a process.

Transition: a transition refers to the change in security context for a requested operation. Transitions fall into one of two categories. The first category is a transition of process domains. When you execute a program of a given type, a transition may be made from the current domain of the process to a new domain. To illustrate this, I'll use the newrole command. The newrole command is used to change your role, say, from user_r to sysadm_r, assuming you have been granted access to sysadm_r. If you start off as user_r, the general unprivileged user role, and run newrole -r sysadm_r to change to sysadm_r, the system administrator role, a transition is made from your user_t domain to newrole_t (the domain in which the newrole process runs) and from there on to the sysadm_t domain.

The second transition category is the transition of file type when you create a file under a particular directory. If a user creates a file in his own home directory, that file is labeled as user_home_t. But if that same user creates a file in /tmp, that file is labeled user_tmp_t. user_tmp_t is derived from the type of /tmp, which is tmp_t, and the domain of the creating process, which is user_t. When the user creates a file under /tmp, a transition to the user_tmp_t type is made.

Policies: a policy determines what actions can be taken on various types by various domains. All dæmons have their own policies, and the naming convention is of the form dæmon-name.te—postfix.te, apache.te and so forth. As the system administrator of an SE Linux machine, you can edit your policy files to suit your requirements. The policy database is a compiled form of the policy source files and is loaded by the kernel at boot time.

The spasswd program on an SE Linux system is used to change your password. spasswd actually is a wrapper for the standard passwd command used on Linux systems; it ensures that the passwd program is run in the correct domain. It also ensures that your SE Linux identity matches your regular UNIX account name. Earlier I mentioned that regular UNIX user IDs are quite different from SE Linux identities, so why do they have to match when running spasswd? spasswd requires you to have the same SE Linux identity name as your UNIX account name. Recall that on an SE Linux system, your identity is the only unique method of determining who you are. So if you're not currently the corresponding UNIX user, you cannot change the password.

If you are the system administrator user (sysadm_r), the sadminpasswd program is used to change the password of another user. sadminpasswd does not have the same matching user name/identity restriction that spasswd has, but sadminpasswd can be run only by sysadm_t.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix