This article is part of the TechXchange: Cybersecurity
Download this article in PDF format.
These days, security is one of those things everyone talks about and in this arena, many actually do something about it. Using mandatory-access-control (MAC) systems like SELinux and AppArmor can significantly improve the security of a system, but only if they’re used. For this discussion, we concentrate on SELinux. However, the ideas are applicable to most access-control systems.
Security-Enhanced Linux or SELinux was initially developed by the US National Security Agency (NSA). It’s standard fare on Red Hat Enterprise Linux (RHEL), the community version called CentOS, and Fedora Linux. It works many other incarnations, although it’s not always installed or turned on by default.
Disabling SELinux is easy. Just run setenforce 0. Turning it off permanently is done by setting SELINUX=disabled in the /etc/selinux/config file for CentOS or Fedora.
JUST DON'T DO IT.
Too many “tips” on the web tell readers to do just this when a particular application will not run with SELinux. It’s usually because they’re too lazy to figure out why. While this will typically get an application to run also turns a relatively secure system to a relatively insecure system.
The reason most of these tips arise is that there are few good presentations of SELinux, or other access-control systems, that can be easily found and readily available. Some of the good books on SELinux also tend to be rather daunting; the excuse for not reading them is that security is not important, not my job, etc.
Unfortunately, getting things to work under SELinux is actually not that hard. Still, there are many cases where it can be more challenging. More on that later.
So, before you disable SELinux completely, take a look at some of the less severe changes that will likely get your application to run.
First off, one needs to understand what SELinux is up to. Really providing a good SELinux overview does take at least a chapter or two of a book, so this will be a bit abbreviated.
Essentially all items that SELinux is protecting, including files, directories, ports, etc., have a label for the form user:role:type. Listing the labels for files and directories is built into ls (Fig. 1). The labels are used by SELinux to determine what security profiles apply to the item.
1. The ls -Z command lists SELinux labels for files and directories.
The label can be changed using the chcon program, but it’s better to use an SELinux context managed using the semanage program along with the restorecon program (Fig. 2). Typically, an application that has been configured for SELinux will include a profile with contexts that define how labels will be set for files, directories, etc. used by the application.
2. The restorecon application changes file and directory labels based on the saved file context (fcontext). The semange program is used to manipulate SELinux contexts.
What often happens is that a user will create or edit files associated with an application such that the labels are incorrect. Of course, SELinux then prevents the application from using these files, as it should. Running restorecon on files and directories where errors occur should be the first step to getting an application to run properly under SELinux.
SELinux Audit Trail
The file /var/log/audit/audit.log (Fig. 3) in CentOS and Fedora is where SELinux errors and actions are logged. Actions that are denied can be found by filtering the file using tools like grep. The log entries tend to be cryptic, but they provide information that can be used to address applications that aren’t working with SELinux.
3. The file /var/log/audit/audit.log can be filtered using tools like grep to display actions that have been denied by SELinux.
Keep in mind that SELinux can run in one of three modes: off, permissive, and enforcing. The former has SELinux doing nothing. Permissive and enforcing have SELinux watching the system. However, permissive simply adds entries to the audit log file while enforcing prevents applications from using an item. We always want SELinux to be enforcing, but we also want applications to run.
The typical recommendation after setenforce 0 is to run SELinux in permissive mode so that it will hopefully generate an audit trail with denial that can then be used to generate a security profile that allows an application to run. The profile can be generated using the log entries and the audit2allow program.
While grep and similar tools are useful for filtering the audit log, SELinux comes with the ausearch program that’s often preferable for use with audit2allow (Fig. 4). It can filter entries based on many criteria from hosts to process ids. Check out the main pages for ausearch and audit2allow as with most of the SELinux-related programs mentioned here, since they have many options not covered in this article.
4. The ausearch application can filter the audit log so that audit2allow is able to generate a profile that’s added to SELinux using semodule.
The challenge with audit2allow is that it will create a profile that enables an application to do more than it could without the profile. However, it may not be sufficient to allow the application to run all of the time. This is because the audit log will only have problems related to what the application did during the period of the log. The profile may be sufficient if all of the application’s actions were tested. However, if some were not, then it’s possible that the generated profile would let the application run for some time but then fail or have errors at some point when encountering actions that weren’t tested. Running SELinux in permissive mode again would allow the new denied actions to be recorded so that a new profile could be created.
Using an audit2allow generated profile may provide an application with more access than one may prefer, but this is still better from a security standpoint than allowing all applications free reign within a system. It’s true that the basic Linux security mechanism would still be in play; still, these are more liberal than the confinement provided by SELinux. As noted, the challenge with the audit2allow approach is knowing whether the generated profile is sufficient.
I do recommend that you examine the filtered audit log that will be used with audit2allow first to see whether changing labels will fix the problem. Often setting a file or directory context using semanage, mentioned earlier, will let a program run.
SELinux Variables
Expanding the security limits of an application using audit2allow may be necessary for applications that don’t have SELinux profiles already defined, but many applications come with profiles that include SELinux variables. These variables can be used to change the security limits in a controlled fashion. They’re often handy when trying to get two SELinux-enabled programs to work together, such as the Samba file server and the Apache web server (httpd).
SELinux variables are manipulated using setsebool and getsebool (Fig. 5). Typically, these booleans greatly expand the limits of particular aspects of the associated security profile. For example, the Apache web server will normally be limited to what ports it can use. Setting the httpd_can_network_connect variable on essentially lets the application use any port. This is often done if the port required is unknown or would change in an unknown fashion. It would be better to create a profile that allowed a specific port or range of ports. Nonetheless, at least using the variable doesn’t open other areas where the web server may be limited to.
5. A list of SELinux variables and their values can be obtained using getsebool.
As noted, these variables are sometimes employed to allow two SELinux-enabled programs to work together. This is because profiles are often designed to give an application access to its resources but prevent other programs from accessing them. That would not be the case if a Samba file share was being used for a website.
There are other ways to enable such sharing to occur, but examining even basic examples is beyond the scope of this article. Suffice it to say that you don’t want to disable SELinux and allow for expanded security boundaries using SELinux variables; it’s much preferred to having no SELinux support.
Permissive Domains
Running SELinux in permissive mode allows all applications to run without generating SELinux. However, the problems are still logged in the audit trail. It’s possible to provide this support on a more limited basis using permissive domains (Fig. 6). In this case, SELinux runs in enforcing mode, limiting most applications, though ones within a permissive domain will not have these restrictions causing errors. Any denials will still be logged, but the applications will be allowed to continue unimpeded.
6. Permissive domains provide a selective way of expanding a domain’s security limitations.
Again, using this approach expands the security limits, though it’s in a known fashion where a user, manager, or developer can determine whether this scope is sufficient for a system. Likewise, it’s more limited than turning off SELinux completely.
Some More SELinux Tools
Other tools come in handy when using SELinux. These include:
- aureport – provides a filtered and formatted report of the audit log
- avcstat – shows access vector cache statistics
- sealart – part of the GUI monitoring system
- seinfo – sdf
- sesearch – searches for SELinux policies for a rule
- sediff – displays differences between SELinux policies
- sechecker – checks SELinux policies
- findcon – searches for files or directories with a desired SELinux contenxt
Most of these aren’t installed when SELinux is running, as they’re often used for status, development, or debugging chores. A system secured using SELinux doesn’t require them, but they’re invaluable when trying to get an application working under SELinux. For example, try sesearch -s httpd_t --allow -d. It lists all of the rules that are associated with files labeled with, or based on, the type httpd_t.
Here are some useful links for more information on SELinux and other security modules:
- https://github.com/SELinuxProject
- http://selinuxproject.org (replaced by https://github.com/SELinuxProject)
- NSA SELinux documentation
- SELinux User's and Administrator's Guide
- Fedora Project SELinux
- org Linux Security Module Usage
- AppArmor
- Simplified Mandatory Access Control Kernel (SMACK) – used by Tizen Linux
- TOMOYO Linux
SELinux and Developers
Providing an application without SELinux support if that application is targeted at platforms where it would be available should be verboten. Security has become critical to the proper operation of PCs, servers, and embedded systems, and not providing this type of security is just poor development practice. It’s also something that’s significantly easier for a developer to include rather than having something attempt to shoehorn an application into an SELinux system after the fact.
Providing support for SELinux, or other access-control systems, requires some understanding of the security environment, which is actually much simpler than most developers might think. Unfortunately, that’s an article for another day.
Hopefully this article provided enough impetus to prevent you from disabling SELinux.
Read more articles at the TechXchange: Cybersecurity
