|Main Archive Page > Month Archives > linux-security-module archives|
AppArmor Security Goal
Crispin Cowan, PhD
This document is intended to specify the security goal that AppArmor is intended to achieve, so that users can evaluate whether AppArmor will meet their needs, and kernel developers can evaluate whether AppArmor is living up to its claims. This document is *not* a general purpose explanation of how AppArmor works, nor is it an explanation for why one might want to use AppArmor rather than some other system.
AppArmor is intended to protect systems from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. AppArmor addresses this threat by confining the application to access only the resources it needs to access to execute properly, effectively imposing "least privilege" execution on the application.
Applications have access to a number of resources including files, interprocess communication, networking, capabilities, and execution of other applications. The purpose of least privilege is to bound the damage that a malicious user or code can do by removing access to all resources that the application does not need for its intended function. For instance, a policy for a web server might grant read only access to most web documents, preventing an attacker who can corrupt the web server from defacing the web pages.
An "application" is one or more related processes performing a function, e.g. the gang of processes that constitute an Apache web server, or a Postfix mail server. AppArmor *only* confines processes that the AppArmor policy says it should confine, and other processes are permitted to do anything that DAC permits. This is sometimes known as a targeted security policy.
AppArmor does not provide a "default" policy that applies to all processes. So to defend an entire host, you have to piece-wise confine each process that is exposed to potential attack. For instance, to defend a system against network attack, place AppArmor profiles around every application that accesses the network. This limits the damage a network attacker can do to the file system to only those files granted by the profiles for the network-available applications. Similarly, to defend a system against attack from the console, place AppArmor profiles around every application that accessed the keyboard and mouse. The system is "defended" in that the worst the attacker can do to corrupt the system is limited to the transitive closure of what the confined processes are allowed to access.
AppArmor currently mediates access to files, ability to use POSIX.1e Capabilities, and coarse-grained control on network access. This is sufficient to prevent a confined process from *directly* corrupting the file system. It is not sufficient to prevent a confined process from *indirectly* corrupting the system by influencing some other process to do the dirty deed. But to do so requires a complicit process that can be manipulated through another channel such as IPC. A "complicit" process is either a malicious process the attacker somehow got control of, or is a process that is actively listening to IPC of some kind and can be corrupted via IPC.
The only IPC that AppArmor mediates is access to named sockets, FIFOs, etc. that appear in the file system name space, a side effect of AppArmor's file access mediation. Future versions of AppArmor will mediate more resources, including finer grained network access controls, and controls on various forms of IPC.
AppArmor specifies the programs to be confined and the resources they can access in a syntax similar to how users are accustomed to accessing those resources. So file access controls are specified using absolute paths with respect to the name space the process is in. POSIX.1e capabilities are specified by name. Network access controls currently are specified by simply naming the protocol that can be used e.g. tcp, udp, and in the future will be more general, resembling firewall rules.
Thus the AppArmor security goal should be considered piecewise from the point of view of a single confined process: that process should only be able to access the resources specified in its profile:
Security issues that AppArmor explicitly does *not* address: