SELinux provides tools to more finely control the activities allowed to users, processes, and daemons to limit the potential damage from vulnerabilities.

In the third and final part of our server security series, we will look at how we can enhance the security of Linux-based AWS EC2 instances with SELinux. We will learn how to set up SELinux on Amazon Linux, and we will walk through a simple example on Red Hat Enterprise Linux (RHEL).

In Linux, we can easily control access to an individual file or directory by modifying the standard file permissions. We can define if we want to allow read, or write, or even execute permissions to the file owner, to all members of a single group, or to everyone else. If the standard file permissions are insufficient, we can also define Access Control Lists (ACL) which allow us to set permissions on an even finer scale.

However, there is an obvious limitation to this type of access control: there is no good way to restrict or limit a process from accessing files and directories that it should not have access to in the first place. For example, an Apache web server should have access to /var/www/html/index.html, but not /etc/passwd.

This limitation can be addressed by using SELinux as an additional layer of access control. The main model used is called Type Enforcement where processes and file system objects are labelled based on their types. SELinux compartmentalizes processes by defining rules around the types in its policy to determine what the processes are allowed to access. SELinux policies deny everything by default unless it is explicitly allowed.

Activating SELinux

On Amazon Linux AMI release 2015.09, SELinux is disabled by default. I am not sure what the state of SELinux is on Amazon Linux but, in any case, you can enable it by performing the following steps.

Install the selinux-policy, selinux-policy-targeted and policycoreutils-python packages, and ensure that SELinux is configured to be enforced.

After that, edit the menu.lst file and append "selinux=1 security=selinux" at the end of the kernel command:

Finally, create an empty .autorelabel file in the root directory to label the entire system with the SELinux context after the instance is rebooted. It will take some time, especially since this is the first time SELinux is enforced on the instance. We need to perform this step to avoid potential issues arising from mislabelled files.

In the system log, you will see the following message before it is rebooted again.

Once the system reboots by itself for the second time, you will find that SELinux is enforced.

Now we’ll walk through a simple example of how SELinux enforces its policy. We will change the default port number of the OpenSSH service and see how SELinux reacts. We will use Red Hat Enterprise Linux 7.1 to modify the SELinux policy so that we can use the new port number – although we could perform (almost) the exact same steps on Amazon Linux.

Make sure you modify your EC2 instance’s Security Group to include this "Custom TCP Rule" before proceeding further.

SELinux

On Red Hat Enterprise Linux 7.1, SELinux is enabled and enforced by default.

We know that the default port number for the OpenSSH server is 22. We want to change it to port 31337. We can do so by modifying the /etc/ssh/sshd_config configuration file to include "Port 31337".

After modifying the sshd_config configuration file, we can restart the OpenSSH service.

But before we restart the service, let’s install the setroubleshoot-server RPM package for the sealert tool. I am unable to find this package on Amazon Linux, but it is available on Red Hat Enterprise Linux.

Everything that SELinux has denied will be logged in /var/log/audit/audit.log. In order to make sense of the logs, you can use the sealert to diagnose the denial messages in layman’s terms. It provides easy-to-understand explanations of the messages and suggests how we can go about addressing such denials next time.

Now we are ready to restart the OpenSSH service.

You will find that the OpenSSH service will not start. This is because the SELinux policy insists that the OpenSSH service should only bind the default port 22. If it finds that it uses a different port, it will not allow it. You can look at the /var/log/audit/audit.log log file to find the offending SELinux denial message.

Now let’s see what the sealert tool says.

Working with SELinux types

The sealert tool hinted that if we wanted to bind a different port, we would have to modify the SELinux port type to include the new port number.

Once we have modified the SELinux SSH port type, let’s restart the OpenSSH service and see if it worked this time.

Awesome! It worked! I hope this article gives you the confidence to learn and explore using SELinux on your EC2 instance.