Application Whitelisting for Linux
Protecting endpoints is hard. Understatement of the millennium, right?
Protecting unmanaged endpoints is even harder. Doubtful that surprises anyone.
Protecting mission-critical, unmanaged endpoints? Well, saying it's impossible is a stretch, but superlatives are warranted.
One of the most common goals in system security is maintaining system integrity. Knowing what is running (or can run) on the deployed system is critical, especially in embedded and unmanaged use cases.
Enterprise and managed endpoints are not immune from these concerns either.
The countless servers and devices that drive the modern world and economy require the same assurances; the difference being the enterprise world usually has more infrastructure and connectivity to achieve these goals.
If we roll back the clocks to early 2018, maintaining system integrity was already a common requirement for many systems. Then came Spectre and Meltdown and the (still) ongoing procession of speculative execution attacks. These threats allow an attacker to extract sensitive information without exploiting the system's applications. An attacker can execute their own crafted application to exploit the processor architecture flaws to inadvertently spill key material, functional details, or other secrets.
So, as system engineers and platform providers, we all know we have a hard challenge whose importance has only increased. Reviewing the various industry standards and existing technology solutions, the consensus has largely settled on Application Whitelisting (AWL) as the default means to protect system integrity.
If you are new to the concept of AWL, the best overview of its principles and possible approaches is NIST SP 800-167. This document will inform the reader of the generalized methodologies, concerns, and trade-offs in the AWL domain.
If you are reading this article and looking for AWL solutions for non-Linux systems, then you will be disappointed. Microsoft, CarbonBlack, etc. have solutions more applicable outside to non-Linux platforms. See this background article for more details for multiple platforms, especially non-Linux use cases.
Sadly, if you review the Linux entry of that last article, you will be left wanting, as there is a lack of clear AWL solutions for Linux-based systems. Now, that article is a bit dated (from 2016), but the Linux landscape as of the publication of this article has not greatly changed - there is a variety of approaches to AWL on Linux, all with varying levels of maturity, complexity, and portability.
Application Whitelisting Linux Options
What follows is a survey of AWL technologies for Linux. This is neither an exhaustive listing, nor does it cover any non-public solutions. We conclude with Star Lab’s own Titanium Technology Protection and how it tackles the AWL requirement (if you are already familiar with Integrity Management Architecture and other AWL technologies for Linux, click here to the Titanium Technology Protection section).
Integrity Measurement Architecture (IMA)
The Integrity Measurement Architecture kernel subsystem (IMA) is arguably the most pervasive and well-known Linux integrity approach, which is not surprising since its introduction goes back to v2.6.30 of the Linux kernel.
At a high-level, IMA first measures file contents and metadata, which are recorded as keyed hashes or signatures within extended file system attributes, and then the integrity of the hashes / signatures is protected by system-level keys and additional measurements. The Linux kernel is then responsible for appraising or validating the file measurements during runtime, where file operations or execution is denied if the current file state doesn't not match the measured file state.
The IMA subsystem uses policy files to dictate what files systems and file types are measured and protected by the kernel. To achieve a measure of AWL, the system must be configured with a policy that limits execution only to those files that are attested by IMA.
The included links to the IMA wiki and publicly available presentations and papers on IMA can provide a more exhaustive review of its inner-workings and usage. Here we make note of a few critical requirements and challenges to IMA.
First, using IMA requires you have a kernel with IMA enabled (i.e., compiled into the kernel) and support for extended attributes in the file systems. Now, the latter may seem trivial on modern systems; however, there are still all kinds of use cases and deployment models where extended attributes are not available, e.g. systems reliant on older versions of NFS. Also, the target file system must support the inode version field in order to update any measured files in the field. This is further limits potential use cases and configurations.
From a performance standpoint, I did not find specific metrics that characterize the performance impact of IMA, especially on boot/start up times. However, I would expect there is a noticeable impact due to need to read an entire file to attest its integrity. Now, this is likely a one-time hit for most files, but it is expensive in terms of I/O and the page cache utilization to read all of a file in order to load or open it.
In terms of portability, tooling, and documentation, IMA is likely the most mature AWL solution for Linux in that it has been around the longest. Still, much is left to the user to configure and deploy per use case, so it is a non-trivial task to implement.
Lastly, achieving robust integrity protections with IMA does require protecting the system from offline attacks (powered-off file modifications and measurement tampering) via the Extended Verification Module (EVM). This also adds a requirement for a Trusted Platform Module (TPM) or hardware root of trust. This is not unique to IMA—I’m just noting it as a deployment constraint / requirement for the most secure configurations.
In summary, IMA does leverage robust cryptographic attestation and a mature key management architecture, making it a viable solution for standalone systems that come under serious threats. Note that platform owners should prepare to expend non-trivial resources to configure the system properly, audit the configuration, and maintain it.
RedHat Enterprise Linux 8 fapolicyd
RedHat Enterprise Linux (RHEL) 8 introduced a new file-access policy daemon called `fapolicyd`. The RHEL 8 AWL documentation page explains the various components and basic usage of `fapolicyd`.
With `fapolicyd`, achieving its version of AWL is based on populating a system-wide policy and trust database for all the applications that are allowed to execute. The aforementioned database contains the trusted file's path and integrity measurements. More details about the internals of the daemon, enforcement, and the management of policy can be found on the `fapolicyd` GitHub page.
In terms of enforcement, the `fapolicyd` daemon gets notifications from the kernel's file system notification subsystem, in particular it relies on new event types indicating a file is being opened for execution. The `fapolicyd` daemon evaluates if the target file allowed to execute per the policy and trust database, which requires validating its integrity using a chosen measurement technique.
Looking at the documentation of `fapolicyd`, in particular the FAQ on the GitHub page, it is clear that trust in files and the protection of the database is not yet resilient to attack. Any user with appropriate privileges can modify the database or policies. There does not appear to be any protection from modification other than basic user access controls. As such, it would be trivial for an attacker with administrative privileges to subvert `fapolicyd` in its current form.
Also, it is not clear what the performance impact of this approach would be, but the necessity for the kernel to transmit events to user space and the reliance on IMA and/or the daemon performing its own hashes does not suggest minimal overhead. Making enforcement decisions across user space and kernel space is always going to introduce overhead, let alone it creates multiple opportunities to subvert the system depending on where an attacker has a foothold.
Now, it is absolutely true that `fapolicyd` is very new and will continue to mature. There is no doubt it will get better over the coming months and years given its exposure in RHEL 8. Still, there are many opportunities for improvement to make it a viable AWL solution for critical systems that can adopt more modern kernels.
Microsoft Integrity Policy Enforcement
Much to the surprise of some Linux users and fans, Microsoft has become one of the biggest contributors and users of Linux. Linux is now available in Windows 10 (see WSL), and Linux is used throughout the Azure cloud, both as an infrastructure component and available to customers in virtual machines.
Not surprisingly, Microsoft is now looking to boost the system integrity capabilities natively available in Linux. Earlier in 2020, Microsoft proposed a new system integrity solution called Integrity Policy Enforcement (IPE).
IPE is implemented as a new Linux Security Module (LSM), where it is intended to be a runtime enforcement mechanism for a form of AWL. The IPE LSM has not yet been merged into the mainline Linux kernel (here are the latest patches at the time of publication of this article).
To provide AWL, the IPE LSM only allows execution for applications sourced from an initial boot partition / block device or read-only integrity verified block devices (using the dm-verity framework). It is mentioned in the IPE documentation that future patches / changes would also allow applications from integrity verified file systems using the Linux fs-verity framework, but this does not yet appear to be in the latest IPE patches linked earlier.
It is likely that IPE will be a very performant but rigid AWL solution for Linux. The implementation of IPE as an LSM while relying on block layer and file system verification layers means that the integrity attestation is going to happen efficiently in terms of I/O operations. Note, this solution currently relies on the backing device to be read-only, so it will likely be targeted at very static, non-volatile systems.
As the Microsoft IPE page indicates, achieving robust system integrity will require verification of the platform firmware and kernel / boot components. This will likely incorporate a form of secure or measured boot and possibly a TPM, like IMA.
Star Lab Titanium Technology Protection
The Titanium Technology Protection included an AWL capability starting in v7.0 released in 2019. Ongoing work on Titanium Technology Protection AWL has continued, with additional integration and capabilities in the latest release as of this article's publication date (see v8.0 blog post).
A product overview is found in a previous blog post. That article introduced the two overlay file systems FortiFS and AuthFS, both are critical to much of Titanium's capabilities. The file systems strongly authenticate the underlying files using HMAC-SHA-256 and an optimized page-level attestation approach (FortiFS also encrypts files); authenticating memory pages as they are being read for execution, as opposed to authenticating the entire file contents on first access. This optimization significantly reduces the boot-time hit incurred by the aforementioned file-level AWL approaches.
AWL with Titanium Technology Protection starts with protecting / provisioning the executables and libraries that make up the "trusted" applications. This provisioning process is what creates the HMAC measurements associated with each file. When Titanium for Linux kernel with the Titanium LSM is booted, the FortiFS and AuthFS vaults (authenticated directories) are mounted after system-level keys are loaded, and once mounted, any attempt to read, write, and execute a file in a vault requires validating the file's integrity.
Enforcing AWL in Titanium Technology Protection is simply the strict enforcement that any page of memory mapped for execution must be backed by AuthFS or FortiFS and the page's integrity confirmed. There is no actual database, manifest, or trust list. Like IMA and IPE, integrity verification in the Titanium for Linux kernel establishes the trust to allow execution. However, unlike IMA and the others mentioned above, Titanium Technology Protection does enforce AWL against all pages of memory loaded for execution, including TMPFS, and does not require configuring protections based on known file types or media configuration.
The Titanium LSM and file systems are independent components that have been developed and maintained by Star Lab. There are neither special features or recent kernel changes required by the Titanium Technology Protection AWL capabilities, nor do AuthFS or FortiFS rely on extended attributes or properties of underlying file systems. To date Titanium has been integrated into kernels as old as v3.10.x, and both file systems can be deployed on top of NFS or other network-based file systems.
To achieve full system integrity and protect against offline attacks, the Titanium for Linux kernel and initramfs should be protected and verified using Titanium Secure Boot. Like IMA and IPE, this leverages a TPM or hardware root-of-trust.
In terms of maturity and capabilities, Titanium Technology Protection most closely compares to IMA. Both rely on cryptographic measurements and robust key management. Both are in-kernel enforcement mechanisms that operate at the file-level. Both are portable to many configurations, architectures, and kernel versions. The biggest differences are in how the system is provisioned, how integrity measurements are stored, and tooling. In general, I'd characterize the difference as Titanium sacrifices a little more physical disk space to achieve more efficient verification, portability, and greatly simplify tooling and maintenance. Also, Titanium Technology Protection-protected files can be moved across systems and devices without compromising their integrity or complicating validation.
Note: In support of cyber security industry changes to terminology and as further referenced in the kernel mailing list for this subject, Titanium Technology Protection will move from using “Application Whitelist” terminology to “Application Allowlist” in future releases. This will impact both the documentation and the exposed features and controls in the product itself.
Summary
The demand for AWL solutions on Linux-based systems will continue to grow for the foreseeable future. The recent revelations of speculative execution attacks and the complexity of fixing the processor architectures requires that software-based solutions like AWL be more readily available for embedded and unattended systems.
Using AWL for Linux is possible using various methods, but there are key trade-offs and constraints that dictate which solution is most appropriate for a given configuration and how much effort will it take to implement. Microsoft IPE and RHEL `fapolicyd` are the newcomers in the AWL space that rely on the latest kernel features, but it is clear that neither is mature enough to be a reliable solution for critical systems.
Titanium and IMA are both available for a variety of configurations that need more mature solutions, but the use case, maintenance model, and security requirements of the deployed system will likely steer to one solution over the other.
