Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 

<< Previous SELinux Introduction
Table of Contents
SELinux Installation Next >>

2. Overview

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.

2.1 Why SE Linux?

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.

2.2 Terminology used

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 ;)

2.2.1 identity


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.

2.2.2 domain

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.

2.2.3 type


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.

2.2.4 role


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.

2.2.5 security context


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.

2.2.6 transition

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.

2.2.7 policy

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.

 
 
  Published with kind permission of Faye Coker Design by Interspire