[AppArmor 47/47] --- Documentation/lsm/AppArmor-Security-Goal.txt | 134 +++++++++++++++++++++++++++ 1 file changed, 134 insertions(+)

[John@suse.de, Johansen@suse.de]

--- /dev/null
+++ b/Documentation/lsm/AppArmor-Security-Goal.txt
@@ -0,0 +1,134 @@
+AppArmor Security Goal
+Crispin Cowan, PhD
+MercenaryLinux.com
+
+This document specifies 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 limit system damage 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 interact with the rest of the system via 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 resources that the application does not need for its intended
+function. This is true for all access control systems, including AppArmor.
+
+The "attacker" is someone trying to gain the privileges of a process for
+themselves. 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. A web server has
+access to the web server's local file system, and a network attacker
+trying to hack the web server does not have such file access. An e-mail
+attacker attempting to infect the recipient of the e-mail does not have
+access to the files that the victim user's mail client does. By limiting
+the scope of access for an application, AppArmor can limit the damage an
+attacker can do by exploiting vulnerabilities in applications.
+
+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:
+
+    * can only access files that are reachable in its name space by path
+      names matching its profile, and only with the permitted modes:
+      read, append, write, memory map, execute, and link
+    * can only use the POSIX.1e capabilities listed in the profile
+    * can only perform the network operations listed in the profile
+
+Security issues that AppArmor explicitly does *not* address:
+
+    * Processes that are not confined by AppArmor are not restricted in
+      any way by AppArmor. If an unconfined process is considered an
+      unacceptable threat, then confine additional applications until
+      adequate security is achieved.
+    * A process that is not permitted to directly access a resource can
+      influence some other process that does have access to the resource
+      may do so, if the "influence" is a permitted action.
+    * A confined process may only access a file if it has at least one
+      of the files aliases specified in its profile.  If a file alias is
+      not specified in the profile then it can not be accessed by that
+      path.  The creation of aliases needs to be tightly controlled in
+      confined applications, hard links creation should be limited to
+      provide adequate security.
+    * A confined process can operate on a file descriptor passed to it
+      by an unconfined process, even if it manipulates a file not in the
+      confined process's profile. To block this attack, confine the
+      process that passed the file descriptor.
+    * Process activities not currently mediated by AppArmor are
+      permitted, e.g. confined processes can perform any IPC that DAC
+      permits, other than signals as mediated by CAP_KILL.
+    * Manipulating AppArmor policy requires being both root privileged
+      and not being confined by AppArmor, thus there is explicitly no
+      capability for non-privileged users to change AppArmor policy.
+    * AppArmor confines processes if they are children of a confined
+      process, or if the name of the exec'd child matches the name of an
+      AppArmor profile. Another process could copy a program to a
+      different path name and then execute it without confinement, but
+      the other process would have to have permission to do so in the
+      first place. To prevent this, confine the other process and
+      additional applications until adequate security is achieved.
+    * Mount and namespace manipulations can be used to arbitrarily
+      change the pathnames that files appear at, and thus completely
+      bypass AppArmor policy. To prevent this, processes confined by
+      AppArmor are currently not permitted to call mount or manipulate
+      name spaces at all. A future development may provide more granular
+      controls on mount and namespace manipulations.
+    * AppArmor does not slice bread, cure cancer, bring world peace, or
+      provide perfect security. This list may be expanded :-)
+
+

-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/