Following is a short discussion on why you should consider using SE Linux and how it fundamentally works. Section 2.2 defines terms that will frequently be used in subsequent sections, so get familiar with them now.
Another example is if there was an exploitable bug in /usr/bin/passwd which could run chmod 666 /etc/shadow SE Linux permissions would still prevent anyone from inappropriately accessing the file.
Rather than regurgitate what is written in the NSA's FAQ, I'll point you straight there. Reading the white papers the NSA has published is a must.
Example:
An unprivileged user with the login name faye runs the id command (under SE Linux) and sees the security context of
context=faye:user_r:user_tThe identity portion of the security context in this case is "faye". Now, if faye su's to root and runs id, she will see the security context is still
context=faye:user_r:user_tso the identity remains the same, and has not changed to root. However, if identity faye has been granted access to enter the sysadm_r role and does so (with the newrole -r command which will be covered later), and runs id command again, she will now see
context=faye:sysadm_r:sysadm_tSo 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 is also crucial to system security in that the user identity will determine what roles and domains can be used.
Some examples of domains are sysadm_t which is the system administration domain, and user_t which is the general unprivileged user domain. init runs in the init_t domain, and named runs in the named_t domain.
Example:
In order to allow a user from the user_t domain (the unprivileged user domain) to execute the passwd command, the following is specified in the relevant config file:
role user_r types user_passwd_tIt shows that a user in the user role (user_r) is allowed to enter the user_passwd_t domain i.e. they can run the passwd command.
There is a very important distinction which needs to be made here, between a domain and a type, as it tends to cause a little confusion later on if you don't understand it from the start.
Processes have a domain. When you check the security context of a process (for an example, see the explanation of "transition", below), the final field is the domain such as user_passwd_t (if you were running the passwd command).
Objects such as files, directories, sockets etc have types. When you use the ls --context command on a file for instance, the final field is the type, such as user_home_t for a file created in the home directory of a user in the user_r role.
Here's where a little confusion can creep in, and that's whether something is a domain or a type. Consider the /proc filesystem. Every process has a domain, and /proc has directories for each process. Each process has a label, or rather, a security context applied to a file. But in the /proc world, the label contains a type, and not a domain. Even though /proc is representing running processes, the entries under /proc are considered files and therefore have a type instead of a domain.
Running ls --context /proc shows the following listing for the init process (with a process id of 1):
dr-xr-xr-x root root system_u:system_r:init_t 1The label, or security context, shows that this file has a type of init_t However it also means that the init process is running in the init_t domain. Each file or directory under /proc that has a process id for a filename will follow this convention, i.e. the type listed for that process in the output of a ls --context command will also be the domain that process is running in.
Another thing to note is that commands such as chsid (change the security id) and chcon (change context) don't work on /proc as /proc does not support changing of labels.
The security context of a file, for example, can vary depending on the domain that creates it. By default, a new file or directory inherits the same type as its parent directory, however you can have policies set up to do otherwise.
Example:
user faye creates a file named test in her home directory. She then runs the command ls --context test and sees
-rw-r--r-- faye faye faye:object_r:user_home_t testShe then creates a file in /tmp called tmptest and runs the command ls --context /tmp/tmptest This time, the result is
-rw-r--r-- faye faye faye:object_r:user_tmp_t /tmp/tmptestIn the first example, the security context includes the type "user_home_t" which is the default type for the home directory of an unprivileged user in the user_r role. After running the second ls --context command, you can see that the type is user_tmp_t which is the default type that is used for files created by a user_t process, in a directory with a tmp_t type.
Example:
For the second type of transition (transition of file type), refer to the example give in the "security context" section above. When running the ls --context commands you can see what the file types are labelled as (i.e. user_home_t and user_tmp_t in the above examples). So, here you can see that when the user created a file in /tmp a transition to the user_tmp_t domain occurred and the new file has been labelled as such.
For transition of process domains, consider the following example. Run ssh as a non privileged user, or more specifically, from the user_t domain (remember you can use the id command to check your security context). Then run ps ax --context and note what is listed for ssh. Assuming user faye does this, she sees
faye:user_r:user_ssh_tas part of the output listing. The ssh process is being run in the user_ssh_t domain because the executable is of type ssh_exec_t and the user_r has been granted access to the user_ssh_t domain.