add apparmor security goal documentation

kernel-patches/for-mainline/apparmor-security-goal.diff

@@ -0,0 +1,141 @@
+---
+ Documentation/lsm/AppArmor-Security-Goal.txt |  134 +++++++++++++++++++++++++++
+ 1 file changed, 134 insertions(+)
+
+--- /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 :-)
++
++

kernel-patches/for-mainline/series

@@ -59,6 +59,7 @@ owner-perm-set.diff
 apparmor-link-pairs.diff
 apparmor-bootdisable.diff
 apparmor-builtin-only.diff
+apparmor-security-goal.diff
 #foobar.diff
 # # NOT YET
 # ecryptfs-d_revalidate.diff