2
Documentation/lsm/AppArmor-Security-Goal.txt | 134 +++++++++++++++++++++++++++
3
1 file changed, 134 insertions(+)
6
+++ b/Documentation/lsm/AppArmor-Security-Goal.txt
8
+AppArmor Security Goal
12
+This document specifies the security goal that AppArmor is intended to
13
+achieve, so that users can evaluate whether AppArmor will meet their
14
+needs, and kernel developers can evaluate whether AppArmor is living up
15
+to its claims. This document is *not* a general purpose explanation of
16
+how AppArmor works, nor is it an explanation for why one might want to
17
+use AppArmor rather than some other system.
19
+AppArmor is intended to limit system damage from attackers exploiting
20
+vulnerabilities in applications that the system hosts. The threat is
21
+that an attacker can cause a vulnerable application to do something
22
+unexpected and undesirable. AppArmor addresses this threat by confining
23
+the application to access only the resources it needs to access to
24
+execute properly, effectively imposing "least privilege" execution on
27
+Applications interact with the rest of the system via resources
28
+including files, interprocess communication, networking, capabilities,
29
+and execution of other applications. The purpose of least privilege is
30
+to bound the damage that a malicious user or code can do by removing
31
+access to resources that the application does not need for its intended
32
+function. This is true for all access control systems, including AppArmor.
34
+The "attacker" is someone trying to gain the privileges of a process for
35
+themselves. For instance, a policy for a web server might grant read
36
+only access to most web documents, preventing an attacker who can
37
+corrupt the web server from defacing the web pages. A web server has
38
+access to the web server's local file system, and a network attacker
39
+trying to hack the web server does not have such file access. An e-mail
40
+attacker attempting to infect the recipient of the e-mail does not have
41
+access to the files that the victim user's mail client does. By limiting
42
+the scope of access for an application, AppArmor can limit the damage an
43
+attacker can do by exploiting vulnerabilities in applications.
45
+An "application" is one or more related processes performing a function,
46
+e.g. the gang of processes that constitute an Apache web server, or a
47
+Postfix mail server. AppArmor *only* confines processes that the
48
+AppArmor policy says it should confine, and other processes are
49
+permitted to do anything that DAC permits. This is sometimes known as a
50
+targeted security policy.
52
+AppArmor does not provide a "default" policy that applies to all
53
+processes. So to defend an entire host, you have to piece-wise confine
54
+each process that is exposed to potential attack. For instance, to
55
+defend a system against network attack, place AppArmor profiles around
56
+every application that accesses the network. This limits the damage a
57
+network attacker can do to the file system to only those files granted
58
+by the profiles for the network-available applications. Similarly, to
59
+defend a system against attack from the console, place AppArmor profiles
60
+around every application that accessed the keyboard and mouse. The
61
+system is "defended" in that the worst the attacker can do to corrupt
62
+the system is limited to the transitive closure of what the confined
63
+processes are allowed to access.
65
+AppArmor currently mediates access to files, ability to use POSIX.1e
66
+Capabilities, and coarse-grained control on network access. This is
67
+sufficient to prevent a confined process from *directly* corrupting the
68
+file system. It is not sufficient to prevent a confined process from
69
+*indirectly* corrupting the system by influencing some other process to
70
+do the dirty deed. But to do so requires a complicit process that can be
71
+manipulated through another channel such as IPC. A "complicit" process
72
+is either a malicious process the attacker somehow got control of, or is
73
+a process that is actively listening to IPC of some kind and can be
76
+The only IPC that AppArmor mediates is access to named sockets, FIFOs,
77
+etc. that appear in the file system name space, a side effect of
78
+AppArmor's file access mediation. Future versions of AppArmor will
79
+mediate more resources, including finer grained network access controls,
80
+and controls on various forms of IPC.
82
+AppArmor specifies the programs to be confined and the resources they
83
+can access in a syntax similar to how users are accustomed to accessing
84
+those resources. So file access controls are specified using absolute
85
+paths with respect to the name space the process is in. POSIX.1e
86
+capabilities are specified by name. Network access controls currently
87
+are specified by simply naming the protocol that can be used e.g. tcp,
88
+udp, and in the future will be more general, resembling firewall rules.
90
+Thus the AppArmor security goal should be considered piecewise from the
91
+point of view of a single confined process: that process should only be
92
+able to access the resources specified in its profile:
94
+ * can only access files that are reachable in its name space by path
95
+ names matching its profile, and only with the permitted modes:
96
+ read, append, write, memory map, execute, and link
97
+ * can only use the POSIX.1e capabilities listed in the profile
98
+ * can only perform the network operations listed in the profile
100
+Security issues that AppArmor explicitly does *not* address:
102
+ * Processes that are not confined by AppArmor are not restricted in
103
+ any way by AppArmor. If an unconfined process is considered an
104
+ unacceptable threat, then confine additional applications until
105
+ adequate security is achieved.
106
+ * A process that is not permitted to directly access a resource can
107
+ influence some other process that does have access to the resource
108
+ may do so, if the "influence" is a permitted action.
109
+ * A confined process may only access a file if it has at least one
110
+ of the files aliases specified in its profile. If a file alias is
111
+ not specified in the profile then it can not be accessed by that
112
+ path. The creation of aliases needs to be tightly controlled in
113
+ confined applications, hard links creation should be limited to
114
+ provide adequate security.
115
+ * A confined process can operate on a file descriptor passed to it
116
+ by an unconfined process, even if it manipulates a file not in the
117
+ confined process's profile. To block this attack, confine the
118
+ process that passed the file descriptor.
119
+ * Process activities not currently mediated by AppArmor are
120
+ permitted, e.g. confined processes can perform any IPC that DAC
121
+ permits, other than signals as mediated by CAP_KILL.
122
+ * Manipulating AppArmor policy requires being both root privileged
123
+ and not being confined by AppArmor, thus there is explicitly no
124
+ capability for non-privileged users to change AppArmor policy.
125
+ * AppArmor confines processes if they are children of a confined
126
+ process, or if the name of the exec'd child matches the name of an
127
+ AppArmor profile. Another process could copy a program to a
128
+ different path name and then execute it without confinement, but
129
+ the other process would have to have permission to do so in the
130
+ first place. To prevent this, confine the other process and
131
+ additional applications until adequate security is achieved.
132
+ * Mount and namespace manipulations can be used to arbitrarily
133
+ change the pathnames that files appear at, and thus completely
134
+ bypass AppArmor policy. To prevent this, processes confined by
135
+ AppArmor are currently not permitted to call mount or manipulate
136
+ name spaces at all. A future development may provide more granular
137
+ controls on mount and namespace manipulations.
138
+ * AppArmor does not slice bread, cure cancer, bring world peace, or
139
+ provide perfect security. This list may be expanded :-)
added
removed
kernel-patches/for-mainline/apparmor-security-goal.diff
