From: John@suse.de, Johansen@suse.de
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: [AppArmor 47/47] --- Documentation/lsm/AppArmor-Security-Goal.txt | 134 +++++++++++++++++++++++++++ 1 file changed, 134 insertions(+)
Date: Thu, 20 Dec 2007 06:09:57 -0800 [thread overview]
Message-ID: <20071220140948.816638552@suse.de> (raw)
In-Reply-To: 20071220140910.934607826@suse.de
[-- Attachment #1: apparmor-security-goal.diff --]
[-- Type: text/plain, Size: 7991 bytes --]
--- /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 :-)
+
+
--
prev parent reply other threads:[~2007-12-20 14:34 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-20 14:09 [AppArmor 00/47] AppArmor security module overview John, Johansen
2007-12-20 14:09 ` [AppArmor 01/47] Pass struct vfsmount to the inode_create LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 02/47] Pass struct path down to remove_suid and children John, Johansen
2007-12-20 14:09 ` [AppArmor 03/47] Add a vfsmount parameter to notify_change() John, Johansen
2007-12-20 14:09 ` [AppArmor 04/47] Pass struct vfsmount to the inode_setattr LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 05/47] Add struct vfsmount parameter to vfs_mkdir() John, Johansen
2007-12-20 14:09 ` [AppArmor 06/47] Pass struct vfsmount to the inode_mkdir LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 07/47] Add a struct vfsmount parameter to vfs_mknod() John, Johansen
2007-12-20 14:09 ` [AppArmor 08/47] Pass struct vfsmount to the inode_mknod LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 09/47] Add a struct vfsmount parameter to vfs_symlink() John, Johansen
2007-12-20 14:09 ` [AppArmor 10/47] Pass struct vfsmount to the inode_symlink LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 11/47] Pass struct vfsmount to the inode_readlink " John, Johansen
2007-12-20 14:09 ` [AppArmor 12/47] Add struct vfsmount parameters to vfs_link() John, Johansen
2007-12-20 14:09 ` [AppArmor 13/47] Pass the struct vfsmounts to the inode_link LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 14/47] Add a struct vfsmount parameter to vfs_rmdir() John, Johansen
2007-12-20 14:09 ` [AppArmor 15/47] Pass struct vfsmount to the inode_rmdir LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 16/47] Call lsm hook before unhashing dentry in vfs_rmdir() John, Johansen
2007-12-20 14:09 ` [AppArmor 17/47] Add a struct vfsmount parameter to vfs_unlink() John, Johansen
2007-12-20 14:09 ` [AppArmor 18/47] Pass struct vfsmount to the inode_unlink LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 19/47] Add struct vfsmount parameters to vfs_rename() John, Johansen
2007-12-20 14:09 ` [AppArmor 20/47] Pass struct vfsmount to the inode_rename LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 21/47] Add a struct vfsmount parameter to vfs_setxattr() John, Johansen
2007-12-20 14:09 ` [AppArmor 22/47] Pass struct vfsmount to the inode_setxattr LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 23/47] Add a struct vfsmount parameter to vfs_getxattr() John, Johansen
2007-12-20 14:09 ` [AppArmor 24/47] Pass struct vfsmount to the inode_getxattr LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 25/47] Add a struct vfsmount parameter to vfs_listxattr() John, Johansen
2007-12-20 14:09 ` [AppArmor 26/47] Pass struct vfsmount to the inode_listxattr LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 27/47] Add a struct vfsmount parameter to vfs_removexattr() John, Johansen
2007-12-20 14:09 ` [AppArmor 28/47] Pass struct vfsmount to the inode_removexattr LSM hook John, Johansen
2007-12-20 14:09 ` [AppArmor 29/47] Fix __d_path() for lazy unmounts and make it unambiguous John, Johansen
2007-12-20 14:09 ` [AppArmor 30/47] Make d_path() consistent across mount operations John, Johansen
2007-12-20 14:09 ` [AppArmor 31/47] Add d_namespace_path() to compute namespace relative pathnames John, Johansen
2007-12-20 14:09 ` [AppArmor 32/47] From: Miklos Szeredi <mszeredi@suse.cz> John, Johansen
2007-12-20 14:09 ` [AppArmor 33/47] VFS: new fsetattr() file operation John, Johansen
2007-12-20 14:09 ` [AppArmor 34/47] Pass struct file down the inode_*xattr security LSM hooks John, Johansen
2007-12-20 14:09 ` [AppArmor 35/47] Factor out sysctl pathname code John, Johansen
2007-12-20 14:09 ` [AppArmor 36/47] Allow permission functions to tell between parent and leaf checks John, Johansen
2007-12-20 14:09 ` [AppArmor 37/47] Switch to vfs_permission() in do_path_lookup() John, Johansen
2007-12-20 14:09 ` [AppArmor 38/47] Switch to vfs_permission() in sys_fchdir() John, Johansen
2007-12-20 14:09 ` [AppArmor 39/47] Fix file_permission() John, Johansen
2007-12-20 14:09 ` [AppArmor 40/47] Export audit subsystem for use by modules John, Johansen
2007-12-20 14:09 ` [AppArmor 41/47] AppArmor: Main Part John, Johansen
2007-12-20 14:09 ` [AppArmor 42/47] AppArmor: Module and LSM hooks John, Johansen
2007-12-20 14:09 ` [AppArmor 43/47] AppArmor: Profile loading and manipulation, pathname matching John, Johansen
2007-12-20 14:09 ` [AppArmor 44/47] AppArmor: all the rest John, Johansen
2007-12-20 14:09 ` [AppArmor 45/47] Add AppArmor LSM to security/Makefile John, Johansen
2007-12-20 14:09 ` [AppArmor 46/47] add simple network toggles to apparmor John, Johansen
2007-12-20 14:09 ` John, Johansen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071220140948.816638552@suse.de \
--to=john@suse.de \
--cc=Johansen@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.