Understanding AppArmor Kernel Enhancement

AppArmor is an old, yet powerful security feature introduced in the Linux kernel in the late '90s to control resources for running programs rather than users. It can be used to easily mitigate the damage caused by adversaries. Learn the basics of the AppArmor and its components

Understanding AppArmor Kernel Enhancement
Photo by Andriy Boechko / Unsplash

Hello everyone! So far we have together learned the basics of Linux Privilege Escalation with Discretionary Access Controls and modern techniques like capabilities and container breakouts. Also, I have discussed Mandatory Access Control with you but have not discussed further abusing such configurations.

This is the first post in the series of advanced Linux privilege escalation where you will learn how to use and later, how to exploit these features to escalate to privileged users. But first, allow me to remind you of the difference between MAC and DAC controls. In the case of MAC, sysadmins create a set of access control lists (ACLs) and each user is linked with a specific access level. In contrast, each resource in DAC has a list of users who can access it.

As a beginner to this let's start with AppArmor...

What is AppArmor and Why it's required?

AppArmor as the name suggests becomes the armour for your system that protect against suspected programs (apps) and is an enhancement to Linux kernel security which is used to confine programs rather than users from accessing a set of resources. It was first implemented in the year 1998 and later became the part of Canonical Ltd and the development is continued. Since it is implemented using the Linux Security Modules (LSM) kernel interface, it means you can install it like any other kernel module. In modern Linux based OS, it is pre-installed and enabled by default. This confinement is enforced to a process at execution time, an already running process cannot be confined, hence this is a loophole an adversary might exploit

To make AppArmor function there are a set of tools and drivers used. One of which we just discussed is its kernel module which gets loaded on the boot time and loads the profiles at boot time. Profiles are the human-readable and configurable component that is used to define the policies and conditions for a program to allow or deny read/write/execute permissions to the program and even work with allowing capabilities. Lastly, there are some utilities that are used to interact with the AppArmor in the kernel (ring0) from user-space (ring3)

Most privileged is the kernel and the least privileged in userspace. Read more

It is used as the systemd service so that you can choose to disable or enable it as per your requirements. In addition to general commands, you can use the following command to unload all the profiles at once

$ sudo /etc/init.d/apparmor teardown
Unload all the AppArmor profiles

Yes, but why not prevent with DAC permissions?

I know you must be thinking about why you need to learn AppArmor in the first place and why not go with old features like capabilities and DAC permissions. Allow me to explain it with a situation: You are a sysadmin and you don't look over the webserver frequently. You are on a vacation and some adversaries managed to upload the shell on the web server running as a www-data user or any other low privileged user. They have all access to the reading root directory. Read access to /etc/group and /etc/passwd is default as it is required by programs even running with different users (read more about file permissions).

They can now perform some post-exploitation enumeration to discover a suitable exploit for persistence or privilege escalation if they manage to find the misconfiguration or exploit in the running application. And let me tell you one thing, nowadays when we have a ton of open-source audit tools like LinPEAS, it is easy to understand and fix the misconfiguration but fixing vulnerable programs is hard as some outdated tools are still required [read more]

With the help of AppArmor, you can have these tools forbidden from accessing certain resources. In the upcoming labs, you will see how to disable read /etc/passwd or /etc/group with cat command and how to harden an already compromised server to prevent executing commands in the root directory.

Understanding The Profiles

AppArmor does not work on its own but you need to specify profiles in its configuration directory, which is by default set to /etc/apparmor.d/. Then the utility such as apparmor_parser is used to parse and load the profiles to kernel dynamically without restarting the system. The template of the profile looks like following

# AppArmor policy for ###NAME###
# ###AUTHOR###
# ###COPYRIGHT###
# ###COMMENT###

#include <tunables/global>

###VAR###

###PROFILEATTACH### {
  #include <abstractions/base>

  ###ABSTRACTIONS###

  ###POLICYGROUPS###

  ###READS###

  ###WRITES###
}
The basic template of the profile file

You can include other profiles or the variables from other files using the #include macro and also add comments using the hash symbol (#) same as bash or python. The PROFILEATTACH placeholder is for the program absolute path you want to confine and the body contains actual definitions of the access control list for the binary.  

The naming convention of the profile file names in the configuration directory is slightly different, slashes (/) in pathnames (of the program) is replaced with dot (.) except for the root. For instance, the /usr/sbin/sysctl profile would be named as usr.sbin.sysctl

A profile definition body also supports using variables and declaring your own variable. The basic variables are store in the tunables/global file and you can see it was imported first. You will learn more features and macros like these in the upcoming lectures where I will guide you in getting your hands dirty with AppArmor profiles.

References