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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
3 hours 25 min ago
- Please correct the URL for Salt Stack's web site
6 hours 37 min ago
- Android is Linux -- why no better inter-operation
8 hours 52 min ago
- Connecting Android device to desktop Linux via USB
9 hours 20 min ago
- Find new cell phone and tablet pc
10 hours 19 min ago
11 hours 47 min ago
- Automatically updating Guest Additions
12 hours 56 min ago
- I like your topic on android
13 hours 42 min ago
- This is the easiest tutorial
20 hours 18 min ago
- Ahh, the Koolaid.
1 day 1 hour ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?