Threat Stack and AppArmor – a Match Made in Cloud Security Heaven!

Recently, we’ve had a few customer inquiries about how the Threat Stack Agent co-exists with AppArmor. This led us into a detailed exploration of AppArmor’s componentry, how it interacts with the kernel audit system, and how customers can effectively use our platform along with AppArmor.

TL;DR: Our agent works fine with AppArmor as long as you’re not relying on auditd. Read on to learn about the testing we did and how our agent interacts with AppArmor.

What is AppArmor?

AppArmor is a Linux kernel security module based on the concept of mandatory access control (MAC) that allows the system administrator to restrict programs’ capabilities with per-program profiles. If you want to ensure that processes are following stricter rules of execution, you can create AppArmor profiles to limit the scope of various operations like file system and network access. If you’re running Ubuntu 7.10 or later (and we hope you’re more current than 7.10!), AppArmor is installed and active by default. Certain packages will automatically install their own profiles in enforce mode, and others can be found within the apparmor-profiles repository. If no profiles are available for an application, users can create and add them to /etc/apparmor.d.

Checking AppArmor Status

If you want check your AppArmor status, run aa-status to see the profiles that are currently loaded and their status:


In this example (a stock Ubuntu 14.04 install running in Vagrant), you’ll see a few terms that are important in leveraging AppArmor: enforce and complain. Profiles in complain mode log out potential security violations, but your process isn’t blocked. Once a profile enters enforcement mode, the process has execution restrictions placed on it.



Threat Stack Agent and AppArmor

The Threat Stack agent works by hooking into the Linux kernel audit framework, normalizing multiple kernel events into a common data structure, and continuously transmitting them to our platform for analysis, correlation, and notification. One sensor in our agent, tsauditd, was built to replace auditd. This allows us to take advantage of the existing kernel audit rules functionality for monitoring syscalls and run in user space, thereby avoiding the pain associated with developing kernel modules and the deployment and maintenance headaches often associated with that style of monitoring agent. Also, tsauditd is incredibly fast and lightweight, consuming minimal CPU and memory resources under load.

On install of the Threat Stack agent, we shut down auditd to allow tsauditd to capture events from the kernel.




Since some customers were concerned that AppArmor wouldn’t be as effective, or that they’d lose visibility into events due to auditd being disabled, we conducted testing using real-world AppArmor profiles provided by several customers to ensure that AppArmor and our agent can work together.

Testing AppArmor and Threat Stack Together

We created two Ubuntu 14.04 Vagrants, loaded customers’ profiles into AppArmor, and installed auditd on each box. We installed the Threat Stack agent on one of the two boxes, which subsequently disabled auditd, and AppArmor logs were no longer found within /var/audit/audit.log. So where did the logs go, and is AppArmor still able to function properly?

There might, in fact, be more than one correct answer to the former question, because without auditd running, AppArmor logs to one or more of these locations:

* /var/log/syslog

* /var/log/messages

* /var/log/kern.log

Apart from potentially changing where you look for your AppArmor logs, Threat Stack does not interfere with AppArmor in any way, and it can actually help alert you to changes made to AppArmor or application profiles. The following Threat Stack alert rule will trigger an alert when AppArmor is stopped and/or all profiles are unloaded:


Here’s the subsequent alert from a user executing apparmor stop:


After verifying that Threat Stack and AppArmor work well together, we were faced with another question: what about everything else that was previously in audit.log?

We knew where to find AppArmor logs, but what if the audit.log was used for more than looking into AppArmor history? For this issue, we created the ability to turn on raw logging to tsaudit-raw.log, which provides the same in-depth information you’re used to seeing in audit.log.

Our conclusion: Threat Stack and AppArmor running in parallel is a match made in cloud security heaven!

For more information about Threat Stack and AppArmor, and to find out how Threat Stack can help your organization address its specific cloud security needs, set up a call for a quick product demo.