Armor On

Mandatory Access Control (MAC) is a policy-based security framework that augments conventional security systems by providing an additional layer of protection. Unlike normal permissions, which revolve around performing functions on a filesystem, MAC deals with applications rather than files and directories. MAC doesn't replace existing permissions but supplements them. Since Linux Kernel 2.6, all the MAC versions are implemented over the Linux Security Module (LSM) framework. This article will focus on AppArmor [1], which has been around since 1998 and has been supported by Canonical since 2009.

One advantage of a policy-based model is that a policy cannot be changed by the user, unlike normal permissions, which can be changed if you have sufficient rights. Another added benefit is that it is applicable to all users, even those with superuser privileges.

AppArmor: A Beginner's Delight

Policy-based systems have a higher learning curve, but even the most basic MAC will bolster the system security. Many policy-based systems are so complex that users don't delve deeply enough to implement them effectively. One benefit of AppArmor is that it is comprehensive, yet simple enough to deploy with minimal investment of time and training.

Originally created by Immunix in 1998 as SubDomain, the program saw a tumultuous development period with an acquisition from Novel in 2005, after which it was renamed AppArmor, before winding up with Canonical. AppArmor has been included in the default Ubuntu configuration since Ubuntu 7.10 Gusty Gibbon.

AppArmor ensures apps behave in a secure manner and doesn't allow functions that the application is not supposed to perform. It takes control of the system resources and acts as a distributor of those resources to the applications – similar to the walled runtime environment.

Two important models for security systems are:

• Misuse Prevention – A model that works on blacklisting known harmful entities.
• Anomaly Prevention – A model that works on whitelisting entities; it only allows execution of items that are whitelisted and discards everything else.

AppArmor is an amalgamation of both these approaches. For applications that have predefined policies, it acts as a whitelist. For everything else, it is a blacklist and doesn't define a whitelist, although a user can create a policy and define the whitelist for a specific application. AppArmor is application-specific and not user-specific (unlike the alternative Linux MAC tool SELinux).

AppArmor (Figure 1) is implemented as a Linux Security Module (LSM). LSM, which was introduced with Kernel 2.6, is a feature that allows anyone to create a Mandatory Access Control (MAC) policy and insert it in the kernel without the need to wait for a new kernel refresh or maintainer permission.

Figure 1: AppArmor architecture.

LSM provides a complete ring of protection, unlike other options that are implemented at the library layer.

Getting Started

AppArmor comes pre-installed on many Debian/Ubuntu- or SUSE-based distros, and packages are also available. See your own distro's documentation for more on obtaining and installing AppArmor. In addition to the base package, be sure you install the apparmor-utils and apparmor-profiles package for extra tools and profiles.

AppArmor consists of several layered components (Figure 2). Some of the important features are:

• Machine Analyzer – Auto-scans ports, discovers applications listening to the port, detects applications without any profiles, and identifies applications that need to be confined with AppArmor.
• Profile Generator – Static analyzer that identifies the program either as an x86 application or a script and provides a basic template.
• Learn Mode – In this mode, the rules are not enforced but the program is put under a listen mode and any violations are logged.
• Optimizer – Learns from the violations logged and provides iterative questions that help to create a thorough profile with user consent.
• Enforce Mode – In the mode, the new profile is put under check and complete enforcement is applied; all violations are stopped.

Figure 2: Shows the processes involved in AppArmor.

Once you have completed the setup, use the aa-enabled command to check whether the module is functioning. To ascertain what extra functionality it comes with, run the aa-status command with su/sudo and check the output. You will notice an output showing profiles being loaded in different modes.

Each profile is monitored under two modes:

• Complain or Learning or Unconfined Mode – In this mode, the policies are not enforced and the app can work without any restrictions. However, the policies are monitored and all actions will be traced in the logfile. Programs under this profile are governed by normal permissions.
• Enforce Mode or Confined Mode – Policies in this mode are strictly enforced and any violations will be stopped. All actions are traced and inferred to the logfile.

Profiles are written from the perspective of processes and not the system. Creating and managing profiles is the critical task for using AppArmor effectively, and the overall security hinges upon the privileges granted to each profile.

All the profiles created are stored in /etc/apparmor.d directory and are named after the location of the file – with the / separator in the filename replaced with a dot (.), For instance, a script file named test stored in /home/linuxmagazine will be named .home.linuxmagazine.test.

There are multiple ways to create a profile, and the process depends upon the granularity with which you want to filter and monitor the application. You can use the simple profile tool aa-autodep or the more exhaustive utility aa-genprof.

aa-autodep is a basic tool that automatically scans and forms a basic profile of an app or a script. The profile thus created is in complain mode, and as a result, the rules defined are not enforced and only the actions are logged.

aa-genprof offers a more thorough scan of the app or script and generates a complete AppArmor profile. The profile thus created is put in enforce mode, and full compliance of the policy is ensured. Any violation of the policy will result in termination of the process, and changes will be logged.

Scanning an Application

Before I get to the gritty details of profiling, I need a small script. I will use the program shown in Listing 1.

01 #!/bin/bash
02 #AppArmor test script
03
04 touch test.txt
05 echo "File created"
06
07 cp  /home/shashwat/hello.text .
08 echo "File Copied"
09
10 rm test.txt
11 rm hello.text
12 echo "File has been deleted"
13 echo "Test successful"

The test script in Listing 1 performs basic functions of file creation, copying, and removing the files. Four utilities are used in the test script: touch, cp, rm, and echo. All these utilities require different permissions to operate, and this is where AppArmor strikes a chord; it will scan the app recursively, monitoring every aspect of the script.

Save the test script in any folder and rename it aatest. Be sure to give it the execute permission with:

chmod u+x aatest

I will start by generating a new profile with the following command:

aa-genprof aatest

The utility will ask you to run the script in a different terminal to start the scan process. Execute aatest in another window, and once it is completed, return to the scan window. Press s to start the scan. The scanning process consists of two steps:

• utility access
• action(s) performed

Utility access allows you to borrow the right to access a tool. The output from this mode (Listing 2) shows three facets of the app: Profile, which displays the absolute address of the script/app that you are scanning (aatest in this case); Execute, a utility that the script is asking to run (touch, in this case); and Severity, which shows the danger level of the utility (from 1-10 with 1 being lowest security and 10 being highest). The severity will appear for each utility being used in the script (in this case, touch, cp, and rm).

01 [(S)can system log for AppArmor events] / (F)inish
02 Reading log entries from /var/log/syslog.
03
04 Profile:  /home/shashwat/appar_t/aatest
05 Execute:  /bin/touch
06 Severity: unknown
07 (I)nherit / (C)hild / (N)amed / (X) ix On / (D)eny / Abo(r)t / (F)inish

The second step deals with the action performed by the utilities. The user can decide how to address each action performed by the script. Options include:

• Inherit (ix) – Inherits the property of the binary file.
• Child (Cx) – Creates a sub-profile within the main profile; the inherited binary will also be monitored under complain mode.
• Deny – The resource will be denied during the execution of the program.
• Abort – Exit the AppArmor profile scan without writing any changes to the profile.
• Finish – Exit the profile scan after writing the changes to the profile.

Because I will use the test script in the terminal, rights to read and write in teletypewriter (tty) will also be included, in addition to the actions performed by other tools, such as write, read, and execute functions performed in the scripts. This step also includes a modified parameter for file functions. In Listing 3, you can see a new path variable that shows the path of the output, since the first function of the test script deals with the creation of a new file test.txt in the same directory. There is also a new mode section that lists the permission required to perform the function.

01 Adding #include <abstractions/consoles> to profile.
02 Profile:  /home/shashwat/appar_t/aatest
03 Path:     /home/shashwat/appar_t/test.txt
04 New Mode: owner w
05 Severity: 6
06
07  [1 - owner /home/*/appar_t/test.txt w,]
08   2 - owner /home/shashwat/appar_t/test.txt w,
09 (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish

Once you have finished granting access to the binaries and function, finish the scan process by pressing f; after this, your program will be monitored within AppArmor.