SELinux Requirements for Ataccama Software

The following article provides more information and context regarding SELinux requirements for Ataccama software.

What Is SELinux?

Security-Enhanced Linux (SELinux) is a technology that sits in between a system call (for example, open a file, close a port) and the system. The module evaluates all actions an application takes and uses a predefined list of permissions to decide whether a call is passed to the system or not. This means that, before SELinux is enabled in restrictive (enforcing) mode, a comprehensive set of rules needs to be defined for each application, listing all operations that the application is allowed to perform. If a rule is not defined for a specific action, the call is automatically not permitted and therefore not executed.

The purpose of SELinux is to limit applications to making only the system calls that they really need, with everything else being blocked. As a result, this protects against many exploits, either by making them impossible or, at the very least, very difficult to leverage.

Where Is SELinux Used?

SELinux is typically employed on Internet-facing services, such as web servers and load balancers, which are obvious attack vectors. For example, if a web server is restricted to writing to the logs, communicating on a single port, and reading the content it should serve, even in cases where there is a bug in its software and an attacker manages to execute malicious code, the web server would still not be able to do anything that does not conform with its permissions in SELinux. In other words, the primary use case for SELinux is to protect against bugs in the code that could be exploited to get processes to perform actions that they are not intended for during standard operation.

At the same time, SELinux is typically not used on systems within a corporate network. Although attacks are still possible in such a setup, the complexity of configuring and maintaining SELinux rules often outweighs the benefits. Due to a patch in a certain library, even a simple recompile could result in a system call being made that is not defined for the application, which in turn, could cause another functionality to fail as SELinux blocks the system call.

On the other hand, for some widely used services, good, community-maintained rulesets are available and updated with new releases, as is the case with Apache HTTP Server. Even though this takes enormous effort, it offers the best defense against remote code execution bugs and other exploits.

Why Is SELinux Not Used Always and Everywhere?

If SELinux provides excellent defense against a number of exploits, why is it not universally used? SELinux is a very complex system as it defaults to blocking application access unless explicitly permitted through a rule. For example, if an application needs to allocate some memory without a corresponding rule in place, the request is automatically denied. This extends to all operations, even seemingly basic ones such as opening a port or a file handle, creating a directory, and so on.

In addition, SELinux introduces a new, much more fine-grained concept of users and groups, on top of the standard user and group permissions in Unix-like OS. For example, this additional configuration makes it possible to allow writing to a file but only when appending, or limit access to only certain libraries or ports. The sheer complexity of this system is a major obstacle for its broader use as it is very difficult to correctly set up. A configuration issue might not show up until months later, once a particular, rarely used function without a matching SELinux rule in place is initiated, causing the application to crash. Troubleshooting the issue is not easy either; some application logs might indicate that there is a permission error, while others might not log anything. Furthermore, even if SELinux is carefully taken into consideration when configuring applications, IT teams in general tend to have very little experience with it, which makes errors practically inevitable. 

Why Does Ataccama Not Support SELinux?

As explained in the previous sections, setting up SELinux for even a simple service that reads a configuration file, writes a log, and opens a port to listen on is already incredible complex even for experienced UN*X admins. On top of creating rules, it is also necessary to maintain them for each new release. For Ataccama software, this means configuring rules for over 16 services that need to open many ports, read and write numerous files, use a lot of libraries and even more optional plugins that in turn consist of other libraries maintained by third parties for communicating with a wide array of data sources, to name only some key operations. In addition, Ataccama ONE codebase is constantly changing, with new features being added and existing functionalities being rewritten, replaced, or retired. With this in mind, it is easy to understand why keeping the SELinux configuration up to date and making sure it covers only the necessary system calls, while also not missing anything, would be a never-ending struggle.

Finally, the cost of creating and maintaining an SELinux configuration for a product as complex as Ataccama ONE Gen2 is nearly equal to the cost of maintaining Ataccama ONE Gen2 itself. The main reason for this is that every change in either the codebase or any SELinux policy would require retesting to ensure that everything still functions as intended. Therefore, due to the extreme effort and costs involved, we cannot commit to running Ataccama ONE Gen2 with SELinux in restrictive mode and require using permissive mode instead.