Introduction to AppArmor
Contents
- Post 1 Introduction (This is it).
- Post 2 AppArmor on Ubuntu.
- Post 3 Anatomy of a Profile.
- Post 4 Generating Profiles.
Introduction
The intent of this post is to increase awareness of AppArmor and encourage it's use by Ubuntu users. Although there are portions of this post that may seem quite technical, it is not my intent to give a full technical review of the workings of AppArmor or compare AppArmor to alternate options, such as SELinux.
From the Novell site :
AppArmor is a security tool and uses name-based mandatory access controls to restrict or confine system access by "at risk" applications. "At risk" applications generally include both server and client applications with network access. In this post I will use Firefox as an example.AppArmor is designed to provide easy-to-use application security for both servers and workstations. Novell AppArmor is an access control system that lets you specify per program which files the program may read, write, and execute. AppArmor secures applications by enforcing good application behavior without relying on attack signatures, so it can prevent attacks even if they are exploiting previously unknown vulnerabilities.
The goal is to apply application specific rules or "profiles" to "confine" Firefox, or any other application, to only the directories, files, and posix 1003.1e draft capabilities needed for normal functioning. In the event Firefox is compromised, Apparmor's confinement helps to prevent the compromising of the system as a whole.
AppArmor is a powerful program and, when an application is confined, AppArmor can restrict the activity of even the root user. AppArmor was designed as an alternative to SELinux and is designed to be easier to use.
AppArmor is configured by writing a profile for an application. Profiles are written one application at at time and and typically targeted at applications which have network access. These profiles are a text files which restrict or confine an application. These restrictions are in addition to the standard Linux permissions. For example, you can not give access to a directory or file with AppArmor if such access violates the permissions.
Let us imagine, for example, your browser, Firefox, is hijacked (due to some flaw in the code). Let us also imagine the cracker may then use Firefox to access your home directory or system files, allowing him or her to read and modify system files and/or execute arbitrary code. This hypothetical flaw in Firefox then leads to an escalation of privileges and root access is obtained.
The "traditional" security model would remedy the problem by first correcting the flaw in the code (ie a "security update" for Firefox) and possibly result in a new rule for HIDS, such as viruses scanners or root kits.
The problem with this model it it does nothing to protect against the next attack, aka a Zero Day Attack. AppArmor adds another check to the system, asking the question, should Firefox be accessing or making changes to system files ? AppArmor confines Firefox and if there is a new exploit, AppArmor will help prevent any escalation of privileges.
I set up a collection of AppArmor profiles here . Additional contributions are welcome (PM me if interested).
References
http://en.wikipedia.org/wiki/Selinux
http://en.wikipedia.org/wiki/AppArmor
https://help.ubuntu.com/8.04/serverg.../apparmor.html
http://www.linux.com/feature/58789
http://www.linuxtopia.org/online_boo...ide/index.html
Bookmarks