To continue my series on Practical Linux Topics, I’ll now jump into SELinux. SELinux in itself is a topic deserving of its own class. As I’ve been studying it I’ve pulled many resources for info. The chapter in Practical Linux Topics best serves as an introductory rather than a complete overview of the topic.

Straight from the man page, “SELinux is a security enhancement to Linux which allows users and administrators more control over access control (What is SELinux, 2017).” It does this by using targeted policies to enforce access controls. Particular to SELinux is also the segregating of applications to ensure they are only accessing what they need and not crawling around the filesystem.

With the goals of SELinux outlined, let’s look into exactly how Practical Linux Topics helped me set it up. I used a CentOS VM for my testing and ran the following command provided by the book to install SELinux:

yum install selinux-policy selinux-policy-targeted libselinux-utils policycoreutils policycoreutils-python mcstrans setroubleshoot-server setools setools-console

This includes the software package and any dependencies. This particular line also installs GUI tools which you may not need if you only use CLI.

The config file for SELinux is /etc/selinux/config. The important things to configure here are the state and the type. There are three possible values for the state:

• enforcing – SELinux security policy is enforced.
• permissive – SELinux prints warnings instead of enforcing.
• disabled – No SELinux policy is loaded.

For my exercise, I loaded mine in permissive mode. An important distinction between permissive and disabled is that permissive will still create logs where disabled will not perform any logging.

There are also three possible values for the type:

• targeted – Targeted processes are protected
• minimum – Modification of targeted policy. Only selected processes are protected
• mls – Multi Level Security protection.

For my exercise, I selected targeted. On my VM no activation was required. I rebooted my VM and it was active. To verify this I ran the following command:

#             getenforce

To this it reported the state of SELinux which was permissive. The following command displays more detailed information on the status of SELinux:

#             sestatus

The initial installation and configuration was very simple. However, an understanding of Contexts is required. For this, I found a better explanation online on the Linux Academy Blog. Everything on a Linux system contains a context, and this context determines what has access to which files directories and applications (K, 2016). These can most easily be viewed with the following command:

#             ls –Z

The basic structure of the context is below:

#             system_u:object_r:httpd_sys_script_exec_t

In this example system_u is the user context, which determines which users can access the file. object_r is the role context which applies to processes and domains. Lastly, httpd_sys_script_exec_t is the type context. Type contexts are the primary ones we are concerned with when trying to secure files. SELinux comes built in with hundreds of default ones that can be modified. You can also create your own contexts if any provided don’t provide sufficient security (or provide too stringent security).

SELinux, usually does a good job assigning default contexts, but it is not perfect. To apply a context you would run a command similar to the following:

#             semanage fcontext –t httpd_sys_content_t new_httpd.conf

In this example fcontext maps context definitions, -t denotes type followed by the context, then the file is listed after the declared context. The following command can be used to undo this change:

#             restorecon new_httpd.conf

Lastly, I’ll briefly touch on some common troubleshooting steps. The two most common reasons for SELinux denying access is because someone or something tried to get access, or there is a typo in a policy. Logs will be the best source for determining whether it was a false positive or a proper deny. The following command can be used to create a custom policy module based on info from denial logs:

#             audit2allow

This should only be used as a last resort because you are essentially creating a security loop hole. Lastly, if you totally give up, you can disable SELinux. The book also provided insight into GUI tools, but I have chosen to skip these because my VM is only using the CLI.

Overall, SELinux is a complex topic. Hopefully this and my sited sources serve as a brief intro into this. I plan on exploring SELinux more in the future to give more in-depth posts. I look forward to exploring more topics in the Practical Linux Topics as well.

References:

Binnie, C. (2016). Practical Linux topics. Berkeley, CA: Apress.

K, E. (2016, November 16). Exploring SELinux: Context – Linux Academy Blog. Retrieved September 23, 2018, from https://linuxacademy.com/blog/linux/exploring-selinux-context/

What is SELinux (2017, November 30). Retrieved September 23, 2018, from http://selinuxproject.org/page/Main_Page