Kernel Korner - NSA Security Enhanced Linux
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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released