The world of computers is always changing, and so must the security models.

Note

This article’s information may be outdated. It is kept here for historical reasons.

Why more security?

A Problem

User permissions have been used for a long time now. These permissions allow read, write, and execute access to certain files by certain users. However, this does not solve the main security problem with Linux. The root, or administrative access. Once a attacker has “root” access, the game is up, and the machine is totally compromised. That is because the root user can do anything to the system. Once, on a test system, I deleted the entire system while it was running. That’s how powerful it is.

A Solution

This is where SELinux comes in. Using a context based permissions, it is able to regulate users and programs to operate within defined parameters and areas. For example, it can limit Samba to only have access to user files, deny a crashed Apache Web Server access to Top Secret files, and deny sending the log files to /dev/null (to be erased), a typical method for attackers trying to cover their tracks.

Example

Think of it as taking a house, and dead bolting each door. Of course, you would never do this, but this is just an example. Now, let’s say your front door is bolted shut, but someone left the wash room window open. So some thief sees this vulnerability, and comes through the window in the middle of the night. He walks quietly to the wash room door, and finds the door locked. Thus he is stopped.

Now, we all know that a good thief (huh?) will be able to unlock that door if he really wants to. But that’s going to take time, and make some noise. All the while you will have the police on way. So a real good thief (???) is going to just leave it at that. You’ll just be missing some Tide in the morning.

How It Works

In essence, what’s going on is it’s encasing each program within a certain area to work. In the example above, the intruder may have crashed the web server, and wants it to access files it normally doesn’t touch. This would be the locked door. Of course they could eventually get through, but now that selinux has an access denied error, and has notified the system admin, they won’t have as much time to do damage.

Supported Systems

Currently Fedora, Redhat Enterprise, Centos, and Gentoo support it.

How to use it

Listing/Copying/Moving Files

File management programs like ls, cp, and mv have had their abilities extended made so they can view and manage the context labels of files. Here is a table of programs and their selinux commands.

For example, most of them have a -Z argument for working with SELinux attributes.

  • ls -Z - shows the selinux contexts of files.
  • cp -Z u:r:t - the new file is relabeled as it is created based on the command line option. The extended GNU option –context is the same as -Z. u:r:t means user:role:type as in user_u:object_r:user_home_t.
  • ps -Z - lists all the processes and their context info.
  • id -Z - Show the current user’s context.

Setroubleshoot

This program notifies the admin of access denials in the system by watching the log files. It can either run as a daemon, or a separate app, as sealert -Sb.

Using system-config-selinux

This is one of the easiest ways to manage the selinux polices.

Issues: can’t change the default file contexts to <<none>>. You have to directly edit the file /etc/selinux/[strict|targeted]/contexts/files/file_contexts.local. See the other file_contexts in that folder for examples.

Chcon and Restorecon

You can change the selinux permissions just like you can for file permissions.

‘‘chcon’’ changes the context. Just remember there are three types:

  • -u User, usually system_u or user_u
  • -? Used for multilevel security (Confidential, Top Secret…)
  • -t Type of file, determining who can use it.

Unlike typical file permissions, you can reset selinux permissions. restorecon restores a file to it’s original context as defined in the file /etc/selinux/[strict|targeted]/contexts/files/file_contexts.

Making a new Policy Module

Policy modules allow you to allow a certain program to do something that other programs aren’t allowed to do. You should always check the file permissions and selinux booleans before you make a module, as incorrect modules can open your system to attack.

We are going to make a policy called “local”.For example, Mozilla Firefox has to do some things that according to strict selinux policy is not allowed. So we would want to write a module for it, rather than allow these action globally.

First, we need to extract the data from the log file. You have two options:

  • /var/log/audit/audit.log if you are using the audit daemon.
  • /var/log/messages if the audit daemon isn’t running, or the error is before the audit daemon starts (boot time)

Notice we use -l to retrieve only the errors from the last boot. We assumed using the audit log file, and this outputs to current directory.

audit2allow -l -m local -o local.te -i /var/log/audit/audit.log

Second, edit the file using a text editor, removing any unneeded items: (‘’nano local.te’’)

module local 1.0;

require {
       class sock_file { getattr unlink };
       type device_t;
       type syslogd_t;
       role system_r;
};

allow syslogd_t device_t:sock_file { getattr unlink };

Third, run checkmodule on it

checkmodule -M -m -o local.mod local.te

checkmodule:  loading policy configuration from local.te
checkmodule:  policy configuration loaded
checkmodule:  writing binary representation (version 6) to local.mod

Fourth, package it into a loadable module.

semodule_package -o local.pp -m local.mod

Last, import it into the selinux policy. This may take a while.

semodule -i ./local.pp`

Conclusion

SELinux has a lot of potential to improve security.