SELINUX: The most effective Access Control policy in LINUX for Security.

Today we’re going to talk about SELinux - Security Enhanced Linux. For the everyday layman SELinux maybe daunting to setup, but is a good introduction into different ways to manage access control to your systems.

SELinux is a project of the United States National Security Agency focused at increasing security in the Linux kernel (particularly, kernel 2.6.x). You are probably already familiar with Discretionary Access Control, as it is the system used by the majority of consumer operating systems. File permissions are determined by the creator/user, in Linux this is the ‘Access Control List’ - think about times where you have used chmod or sudo to assign read or write permissions. Mandatory Access Control (MACBasically, the operating system chooses access based on a security label?rather than the user who authored the file. This mechanism is known as SELinux in Linux.

But beyond that, we tend to entrust our data to many corporations which we don’t want everyone seeing. As a result, enterprise-oriented Linux systems, like RedHat Enterprise Linux (RHEL) automatically have SELinux pre-installed.

Think of it this way: let’s say you work for a hospital; you want to manage records of patients. Typically there are a few trusted individuals who have explicit access to these records (to update them, or manage them), but it is the governing board of regulations or the company itself that dictates how this information is shared. Of course, in a hospital, patient records should be confidential and strictly between patient and doctor. You may want another doctor to access your records, but you wouldn’t want your employer or other hospital admin to.

In other words, there is a hierarchy that defines who has access to certain resources and information. At an organisation level, this is set by regulations. These regulations dictate MAC access.

SELinux adds a parallel set of permissions, in which each process runs with a SElinux security context, and files and other resources on the system are also labeled with a security context. The difference from normal permissions is that a configurable SELinux policy controls which process contexts can access which file contexts. Red Hat provides a default policy which most people use.

Another difference with SELinux, is that to have access to a file, you have to have both regular access and SELinux access. So, even if your process is running as the superuser,?root,?it may be denied access to a file or resource based on the SELinux security context of the process and of the file or resource!

This allows us to limit the scope of security compromises on the system, even to the root account, by ensuring that processes are confined by the SELinux policy and their security context into only being able to do things that they should normally authorized to do.

Here is an example of a normal system that does not have SELinux turned on, which is running Apache HTTPD server :

?The web server is available to remote access over the internet. That means that malicious people can try to break into the system through a security bug in the web server. If they succeed, they will have control of a process running as user apache and group apache. Anything readable by that user can now be accessed by that attacker. This includes files and directories that the web server normally has no business working with. A further local-only security bug in one of those may enable the attacker to gain superuser access.

So How can SELinux change this?

This is the same system, with SELinux turned on. By default, the SELinux policy denies all the access, unless rules are included in the policy which permits certain processes contexts to access certain file and resource contexts. (The reference policy provided by REDHAT has a carefully tuned set of rules for production systems provided for you.)

The web server’s?httpd?process are labeled with SELinux context?System_u:system_r:httpd_t. the important part of the context is the third colon–separated field, the SELinux type :httpd_t.

The files and resources on the system are also labeled with SELinux contexts, and again the important part is the SELinux type. For example, files in?/var/www/html?have the typehttpd_sys_content_t. Files in?/tmp?and?/var/tmp?normally have the type?tmp_t.

The SELinux policy has a rule that allows processes running as?httpd_t?to access files labeled as?httpd_sys_content_t.?There is no rule allowing those processes to access files labeled?tmp_t,so those access will be denied, even if regular file permissions indicate that they should be allowed.

• In order for a process to access a file, it must be permitted both by regular permissions and by the SELinux types and policy. If either regular permissions or SELinux block access, access is denied.
• Note that even if you are logged in as a root! Even though root is always allowed access under regular permissions, the process may be running as a context which is blocked by SELinux.

SELinux Policy

At the heart of SELinux' security engine is its?policy. A policy is what the name implies: a set of rules that define the security and access rights for everything in the system. And when we say?everything, we mean users, roles, processes, and files. The policy defines how each of these entities are related to one another.

Some Basic Terminology

To understand policy, we have to learn some basic terminology. We will go into the details later, but here is a brief introduction. An SELinux policy defines user access to roles, role access to domains, and domain access to types.

Users

SELinux has a set of pre-built users. Every regular Linux user account is mapped to one or more SELinux users.

In Linux, a user runs a process. This can be as simple as the user?jo?opening a document in the vi editor (it will be jo's account running the vi process) or a service account running the httpd daemon. In the SELinux world, a process (a daemon or a running program) is called a?subject.

Roles

A?role?is like a gateway that sits between a user and a process. A role defines which users can access that process. Roles are not like groups, but more like filters: a user may enter or assume a role at any time provided the role grants it. The definition of a role in SELinux policy defines which users have access to that role. It also defines what process domains the role itself has access to. Roles come into play because part of SELinux implements what's known as?Role Based Access Control?(RBAC).

Subjects and Objects

A?subject?is a process and can potentially affect an?object.

An?object?in SELinux is anything that can be acted upon. This can be a file, a directory, a port, a tcp socket, the cursor, or perhaps an X server. The actions that a subject can perform on an object are the subject'spermissions.

Domains are for Subjects

A?domain?is the context within which an SELinux subject (process) can run. That context is like a wrapper around the subject. It tells the process what it can and can't do. For example, the domain will define what files, directories, links, devices, or ports are accessible to the subject.

Types are for Objects

A?type?is the context for a file's context that stipulates the file's purpose. For example, the context of a file may dictate that it's a web page, or that the file belongs to the?/etc?directory, or that the file's owner is a specific SELinux user. A file's context is called its?type?in SELinux lingo.

So what is SELinux policy?

SELinux policy defines user access to roles, role access to domains, and domain access to types. First the user has to be authorized to enter a role, and then the role has to be authorized to access the domain. The domain in turn is restricted to access only certain types of files.

Lets share some Troubleshooting option for Selinux Operation:

• Enforcing to disabled mode ------ Need reboot
• Disable to enforcing mode -------? Need reboot
• Enforcing to permissive mode ---- du? No need reboot .

----- if any system does not work on enforcing mode you can set permissive mode so that it only logged on audit log? …. … then Check if the system ok it must be the SELINUX issue.

• When moving a file the original context move with it.
• When copping a file its different story, a new file will created and normally it will inherit of the parent? directory.
• restorecon? is very nice utility when something wrong on context. It checking context and make sure all files in a directory have as it policy. restorcon check the policy context based on policy.

?----------------------------------------------

Troubleshooting Technique

?

# yum list installed | grep setrouble

# yum install setrouble

• All selinux message are logged with AVC header in audit log
• In message log alert coming with sealert header.? Se-alert sometime provide advisory to find out selinux problem . From this you can find out source contex and destination context . If that was not context it was a problem and its identified easily.?

?

# cat /var/log/audit/audit.log |grep AVC

# cat /var/log/messages |grep sealert

#sealert -l 481aa95c-ef18-479a-90f6-26c60616a691

?-----------------------

• When want to modify context someone… you need to know which context you looking for to take care solution :? the easy solution is to look at the default configuration

# cd /var/www/

# ls -Z

# semanage fcontext -l

semanage fcontext -l|grep http

# yum provides */sepolicy

# yum install policycoreutils-devel -y

# sepolicy manpage -a????? ---> it's help you to? find out correct man page

# mandb

# man -k _selinux??? ---- now its works as previous version.

# man httpd_selinux

# cd /tmp/

# mv * /usr/share/man/man

# mandb

sepolicy manpage -a -p /usr/share/man/man8

• chcon written on inode i.e filesystem know the correct system . When re-level activity occurs it may not work. So always use semanae instead of chcon for selinux .??

Happy Reading / Salim Reza