Root/
1 | # |
2 | # Security configuration |
3 | # |
4 | |
5 | menu "Security options" |
6 | |
7 | config KEYS |
8 | bool "Enable access key retention support" |
9 | help |
10 | This option provides support for retaining authentication tokens and |
11 | access keys in the kernel. |
12 | |
13 | It also includes provision of methods by which such keys might be |
14 | associated with a process so that network filesystems, encryption |
15 | support and the like can find them. |
16 | |
17 | Furthermore, a special type of key is available that acts as keyring: |
18 | a searchable sequence of keys. Each process is equipped with access |
19 | to five standard keyrings: UID-specific, GID-specific, session, |
20 | process and thread. |
21 | |
22 | If you are unsure as to whether this is required, answer N. |
23 | |
24 | config TRUSTED_KEYS |
25 | tristate "TRUSTED KEYS" |
26 | depends on KEYS && TCG_TPM |
27 | select CRYPTO |
28 | select CRYPTO_HMAC |
29 | select CRYPTO_SHA1 |
30 | help |
31 | This option provides support for creating, sealing, and unsealing |
32 | keys in the kernel. Trusted keys are random number symmetric keys, |
33 | generated and RSA-sealed by the TPM. The TPM only unseals the keys, |
34 | if the boot PCRs and other criteria match. Userspace will only ever |
35 | see encrypted blobs. |
36 | |
37 | If you are unsure as to whether this is required, answer N. |
38 | |
39 | config ENCRYPTED_KEYS |
40 | tristate "ENCRYPTED KEYS" |
41 | depends on KEYS && TRUSTED_KEYS |
42 | select CRYPTO_AES |
43 | select CRYPTO_CBC |
44 | select CRYPTO_SHA256 |
45 | select CRYPTO_RNG |
46 | help |
47 | This option provides support for create/encrypting/decrypting keys |
48 | in the kernel. Encrypted keys are kernel generated random numbers, |
49 | which are encrypted/decrypted with a 'master' symmetric key. The |
50 | 'master' key can be either a trusted-key or user-key type. |
51 | Userspace only ever sees/stores encrypted blobs. |
52 | |
53 | If you are unsure as to whether this is required, answer N. |
54 | |
55 | config KEYS_DEBUG_PROC_KEYS |
56 | bool "Enable the /proc/keys file by which keys may be viewed" |
57 | depends on KEYS |
58 | help |
59 | This option turns on support for the /proc/keys file - through which |
60 | can be listed all the keys on the system that are viewable by the |
61 | reading process. |
62 | |
63 | The only keys included in the list are those that grant View |
64 | permission to the reading process whether or not it possesses them. |
65 | Note that LSM security checks are still performed, and may further |
66 | filter out keys that the current process is not authorised to view. |
67 | |
68 | Only key attributes are listed here; key payloads are not included in |
69 | the resulting table. |
70 | |
71 | If you are unsure as to whether this is required, answer N. |
72 | |
73 | config SECURITY_DMESG_RESTRICT |
74 | bool "Restrict unprivileged access to the kernel syslog" |
75 | default n |
76 | help |
77 | This enforces restrictions on unprivileged users reading the kernel |
78 | syslog via dmesg(8). |
79 | |
80 | If this option is not selected, no restrictions will be enforced |
81 | unless the dmesg_restrict sysctl is explicitly set to (1). |
82 | |
83 | If you are unsure how to answer this question, answer N. |
84 | |
85 | config SECURITY |
86 | bool "Enable different security models" |
87 | depends on SYSFS |
88 | help |
89 | This allows you to choose different security modules to be |
90 | configured into your kernel. |
91 | |
92 | If this option is not selected, the default Linux security |
93 | model will be used. |
94 | |
95 | If you are unsure how to answer this question, answer N. |
96 | |
97 | config SECURITYFS |
98 | bool "Enable the securityfs filesystem" |
99 | help |
100 | This will build the securityfs filesystem. It is currently used by |
101 | the TPM bios character driver and IMA, an integrity provider. It is |
102 | not used by SELinux or SMACK. |
103 | |
104 | If you are unsure how to answer this question, answer N. |
105 | |
106 | config SECURITY_NETWORK |
107 | bool "Socket and Networking Security Hooks" |
108 | depends on SECURITY |
109 | help |
110 | This enables the socket and networking security hooks. |
111 | If enabled, a security module can use these hooks to |
112 | implement socket and networking access controls. |
113 | If you are unsure how to answer this question, answer N. |
114 | |
115 | config SECURITY_NETWORK_XFRM |
116 | bool "XFRM (IPSec) Networking Security Hooks" |
117 | depends on XFRM && SECURITY_NETWORK |
118 | help |
119 | This enables the XFRM (IPSec) networking security hooks. |
120 | If enabled, a security module can use these hooks to |
121 | implement per-packet access controls based on labels |
122 | derived from IPSec policy. Non-IPSec communications are |
123 | designated as unlabelled, and only sockets authorized |
124 | to communicate unlabelled data can send without using |
125 | IPSec. |
126 | If you are unsure how to answer this question, answer N. |
127 | |
128 | config SECURITY_PATH |
129 | bool "Security hooks for pathname based access control" |
130 | depends on SECURITY |
131 | help |
132 | This enables the security hooks for pathname based access control. |
133 | If enabled, a security module can use these hooks to |
134 | implement pathname based access controls. |
135 | If you are unsure how to answer this question, answer N. |
136 | |
137 | config INTEL_TXT |
138 | bool "Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)" |
139 | depends on HAVE_INTEL_TXT |
140 | help |
141 | This option enables support for booting the kernel with the |
142 | Trusted Boot (tboot) module. This will utilize |
143 | Intel(R) Trusted Execution Technology to perform a measured launch |
144 | of the kernel. If the system does not support Intel(R) TXT, this |
145 | will have no effect. |
146 | |
147 | Intel TXT will provide higher assurance of system configuration and |
148 | initial state as well as data reset protection. This is used to |
149 | create a robust initial kernel measurement and verification, which |
150 | helps to ensure that kernel security mechanisms are functioning |
151 | correctly. This level of protection requires a root of trust outside |
152 | of the kernel itself. |
153 | |
154 | Intel TXT also helps solve real end user concerns about having |
155 | confidence that their hardware is running the VMM or kernel that |
156 | it was configured with, especially since they may be responsible for |
157 | providing such assurances to VMs and services running on it. |
158 | |
159 | See <http://www.intel.com/technology/security/> for more information |
160 | about Intel(R) TXT. |
161 | See <http://tboot.sourceforge.net> for more information about tboot. |
162 | See Documentation/intel_txt.txt for a description of how to enable |
163 | Intel TXT support in a kernel boot. |
164 | |
165 | If you are unsure as to whether this is required, answer N. |
166 | |
167 | config LSM_MMAP_MIN_ADDR |
168 | int "Low address space for LSM to protect from user allocation" |
169 | depends on SECURITY && SECURITY_SELINUX |
170 | default 65536 |
171 | help |
172 | This is the portion of low virtual memory which should be protected |
173 | from userspace allocation. Keeping a user from writing to low pages |
174 | can help reduce the impact of kernel NULL pointer bugs. |
175 | |
176 | For most ia64, ppc64 and x86 users with lots of address space |
177 | a value of 65536 is reasonable and should cause no problems. |
178 | On arm and other archs it should not be higher than 32768. |
179 | Programs which use vm86 functionality or have some need to map |
180 | this low address space will need the permission specific to the |
181 | systems running LSM. |
182 | |
183 | source security/selinux/Kconfig |
184 | source security/smack/Kconfig |
185 | source security/tomoyo/Kconfig |
186 | source security/apparmor/Kconfig |
187 | |
188 | source security/integrity/ima/Kconfig |
189 | |
190 | choice |
191 | prompt "Default security module" |
192 | default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX |
193 | default DEFAULT_SECURITY_SMACK if SECURITY_SMACK |
194 | default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO |
195 | default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR |
196 | default DEFAULT_SECURITY_DAC |
197 | |
198 | help |
199 | Select the security module that will be used by default if the |
200 | kernel parameter security= is not specified. |
201 | |
202 | config DEFAULT_SECURITY_SELINUX |
203 | bool "SELinux" if SECURITY_SELINUX=y |
204 | |
205 | config DEFAULT_SECURITY_SMACK |
206 | bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y |
207 | |
208 | config DEFAULT_SECURITY_TOMOYO |
209 | bool "TOMOYO" if SECURITY_TOMOYO=y |
210 | |
211 | config DEFAULT_SECURITY_APPARMOR |
212 | bool "AppArmor" if SECURITY_APPARMOR=y |
213 | |
214 | config DEFAULT_SECURITY_DAC |
215 | bool "Unix Discretionary Access Controls" |
216 | |
217 | endchoice |
218 | |
219 | config DEFAULT_SECURITY |
220 | string |
221 | default "selinux" if DEFAULT_SECURITY_SELINUX |
222 | default "smack" if DEFAULT_SECURITY_SMACK |
223 | default "tomoyo" if DEFAULT_SECURITY_TOMOYO |
224 | default "apparmor" if DEFAULT_SECURITY_APPARMOR |
225 | default "" if DEFAULT_SECURITY_DAC |
226 | |
227 | endmenu |
228 | |
229 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9