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.
SE Linux offers greater security for your system. Users can be assigned
predefined roles so that they can not access files or processes that
they do not own. There is no "chmod 777" equivalent operation. This
differs from regular Unix permissions in that the user defined roles,
or security contexts they are placed in, have limited access to files
and other resources but in a far more controlled fashion. Take a user's
.rhosts file on a regular Unix system. If they make
it world writeable then anyone can login and do lots of damage. Under
SE Linux, you can control whether or not the user has the ability to
change the permissions on their
.rhosts file,
and also prevent other people from writing to it even after the owner
has made it world writeable.
A common question is how SE Linux permissions relate to standard
Unix permissions. When you do a certain operation, the Unix permissions
are checked first. If they allow your operation then SE Linux will
check next and allow or deny as appropriate. But if the Unix
permissions don't let you do something, the requested operation stops
there and the SE Linux checks aren't performed.
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.
The following terms will appear frequently in this document, and form
core concepts of SE Linux. It is somewhat tricky to define one word
without including the other terms so I realise my definitions include
things that need defining
;)
An identity under SE Linux is not the same as the traditional Unix uid
(user id). They can coexist together on the same system, but are quite
different. identities under SE Linux form part of a security context
which will affect what domains can be entered, i.e. what essentially
can be done. An SE Linux identity and a standard Unix login name may
have the same textual representation (and in most cases they do),
however it is important to understand that they are two different
things. Running the
su command does not change the user
identity under SE Linux.
Example:
An unprivileged user with the login name faye runs the id
command (under SE Linux) and sees the security context of the 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 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
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.
Every process runs in a domain. A domain directly determines the access a process has. A domain is basically a list of what processes can do, or what actions a process can perform on different types. Think of a domain like a standard Unix uid. Say root has a program and does a
chmod 4777 on that program (making it setuid root). Anyone on the system, even the nobody user, can run this program as root thereby creating a security issue. With SE Linux however, if you have a process which triggers a domain transition to a privileged domain, if the role of the process is not authorised to enter a particular domain, then the program can't be run. 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.
A type is assigned to an object and determines who gets to access that object. The definition for domain is roughly the same, except a domain applies to process and a type applies to objects such as directories, files, sockets, etc.
A role determines what domains can be used. The domains that a user role can access are predefined in policy configuration files. If a role is not authorised to enter a domain (in the policy database), then it will be denied.
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_t It 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.
A security context has all the attributes that are associated with things like files, directories, processes, TCP sockets and so forth. A security context is made up of the identity, role and domain or type. You can check your own current security context by running
id under SE Linux.
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 1
The 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 test
She 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/tmptest
In 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.
br>A transition decision, also referred to as a labelling decision, determines which security context will be assigned for a requested operation. There are two main types of transition. Firstly, there is a transition of process domains which is used when you execute a process of a specified type. Secondly, there is a transition of file type used when you create a file under a particular directory.
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_t
as 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.
Policies are a set of rules governing things such as the roles a user has access to; which roles can enter which domains and which domains can access which types. You can edit your policy files according to how you want your system set up.
