| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | # |
| 3 | # Security configuration |
| 4 | # |
| 5 | |
| 6 | menu "Security options" |
| 7 | |
| 8 | source "security/keys/Kconfig" |
| 9 | |
| 10 | config SECURITY_DMESG_RESTRICT |
| 11 | bool "Restrict unprivileged access to the kernel syslog" |
| 12 | default n |
| 13 | help |
| 14 | This enforces restrictions on unprivileged users reading the kernel |
| 15 | syslog via dmesg(8). |
| 16 | |
| 17 | If this option is not selected, no restrictions will be enforced |
| 18 | unless the dmesg_restrict sysctl is explicitly set to (1). |
| 19 | |
| 20 | If you are unsure how to answer this question, answer N. |
| 21 | |
| 22 | choice |
| 23 | prompt "Allow /proc/pid/mem access override" |
| 24 | default PROC_MEM_FORCE_PTRACE |
| 25 | help |
| 26 | Traditionally /proc/pid/mem allows users to override memory |
| 27 | permissions for users like ptrace, assuming they have ptrace |
| 28 | capability. |
| 29 | |
| 30 | This allows people to limit that - either never override, or |
| 31 | require actual active ptrace attachment (default). |
| 32 | |
| 33 | config PROC_MEM_ALWAYS_FORCE |
| 34 | bool "Traditional /proc/pid/mem behavior" |
| 35 | help |
| 36 | This allows /proc/pid/mem accesses to override memory mapping |
| 37 | permissions if you have ptrace access rights. |
| 38 | |
| 39 | config PROC_MEM_FORCE_PTRACE |
| 40 | bool "Require active ptrace() use for access override" |
| 41 | help |
| 42 | This allows /proc/pid/mem accesses to override memory mapping |
| 43 | permissions for active ptracers like gdb. |
| 44 | |
| 45 | config PROC_MEM_NO_FORCE |
| 46 | bool "Never" |
| 47 | help |
| 48 | Never override memory mapping permissions |
| 49 | |
| 50 | endchoice |
| 51 | |
| 52 | config MSEAL_SYSTEM_MAPPINGS |
| 53 | bool "mseal system mappings" |
| 54 | depends on 64BIT |
| 55 | depends on ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS |
| 56 | depends on !CHECKPOINT_RESTORE |
| 57 | help |
| 58 | Apply mseal on system mappings. |
| 59 | The system mappings includes vdso, vvar, vvar_vclock, |
| 60 | vectors (arm compat-mode), sigpage (arm compat-mode), uprobes. |
| 61 | |
| 62 | A 64-bit kernel is required for the memory sealing feature. |
| 63 | No specific hardware features from the CPU are needed. |
| 64 | |
| 65 | WARNING: This feature breaks programs which rely on relocating |
| 66 | or unmapping system mappings. Known broken software at the time |
| 67 | of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore |
| 68 | this config can't be enabled universally. |
| 69 | |
| 70 | For complete descriptions of memory sealing, please see |
| 71 | Documentation/userspace-api/mseal.rst |
| 72 | |
| 73 | config SECURITY |
| 74 | bool "Enable different security models" |
| 75 | depends on SYSFS |
| 76 | depends on MULTIUSER |
| 77 | help |
| 78 | This allows you to choose different security modules to be |
| 79 | configured into your kernel. |
| 80 | |
| 81 | If this option is not selected, the default Linux security |
| 82 | model will be used. |
| 83 | |
| 84 | If you are unsure how to answer this question, answer N. |
| 85 | |
| 86 | config HAS_SECURITY_AUDIT |
| 87 | def_bool y |
| 88 | depends on AUDIT |
| 89 | depends on SECURITY |
| 90 | |
| 91 | config SECURITYFS |
| 92 | bool "Enable the securityfs filesystem" |
| 93 | help |
| 94 | This will build the securityfs filesystem. It is currently used by |
| 95 | various security modules (AppArmor, IMA, SafeSetID, TOMOYO, TPM). |
| 96 | |
| 97 | If you are unsure how to answer this question, answer N. |
| 98 | |
| 99 | config SECURITY_NETWORK |
| 100 | bool "Socket and Networking Security Hooks" |
| 101 | depends on SECURITY |
| 102 | help |
| 103 | This enables the socket and networking security hooks. |
| 104 | If enabled, a security module can use these hooks to |
| 105 | implement socket and networking access controls. |
| 106 | If you are unsure how to answer this question, answer N. |
| 107 | |
| 108 | config SECURITY_INFINIBAND |
| 109 | bool "Infiniband Security Hooks" |
| 110 | depends on SECURITY && INFINIBAND |
| 111 | help |
| 112 | This enables the Infiniband security hooks. |
| 113 | If enabled, a security module can use these hooks to |
| 114 | implement Infiniband access controls. |
| 115 | If you are unsure how to answer this question, answer N. |
| 116 | |
| 117 | config SECURITY_NETWORK_XFRM |
| 118 | bool "XFRM (IPSec) Networking Security Hooks" |
| 119 | depends on XFRM && SECURITY_NETWORK |
| 120 | help |
| 121 | This enables the XFRM (IPSec) networking security hooks. |
| 122 | If enabled, a security module can use these hooks to |
| 123 | implement per-packet access controls based on labels |
| 124 | derived from IPSec policy. Non-IPSec communications are |
| 125 | designated as unlabelled, and only sockets authorized |
| 126 | to communicate unlabelled data can send without using |
| 127 | IPSec. |
| 128 | If you are unsure how to answer this question, answer N. |
| 129 | |
| 130 | config SECURITY_PATH |
| 131 | bool "Security hooks for pathname based access control" |
| 132 | depends on SECURITY |
| 133 | help |
| 134 | This enables the security hooks for pathname based access control. |
| 135 | If enabled, a security module can use these hooks to |
| 136 | implement pathname based access controls. |
| 137 | If you are unsure how to answer this question, answer N. |
| 138 | |
| 139 | config INTEL_TXT |
| 140 | bool "Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)" |
| 141 | depends on HAVE_INTEL_TXT |
| 142 | help |
| 143 | This option enables support for booting the kernel with the |
| 144 | Trusted Boot (tboot) module. This will utilize |
| 145 | Intel(R) Trusted Execution Technology to perform a measured launch |
| 146 | of the kernel. If the system does not support Intel(R) TXT, this |
| 147 | will have no effect. |
| 148 | |
| 149 | Intel TXT will provide higher assurance of system configuration and |
| 150 | initial state as well as data reset protection. This is used to |
| 151 | create a robust initial kernel measurement and verification, which |
| 152 | helps to ensure that kernel security mechanisms are functioning |
| 153 | correctly. This level of protection requires a root of trust outside |
| 154 | of the kernel itself. |
| 155 | |
| 156 | Intel TXT also helps solve real end user concerns about having |
| 157 | confidence that their hardware is running the VMM or kernel that |
| 158 | it was configured with, especially since they may be responsible for |
| 159 | providing such assurances to VMs and services running on it. |
| 160 | |
| 161 | See <https://www.intel.com/technology/security/> for more information |
| 162 | about Intel(R) TXT. |
| 163 | See <http://tboot.sourceforge.net> for more information about tboot. |
| 164 | See Documentation/arch/x86/intel_txt.rst for a description of how to enable |
| 165 | Intel TXT support in a kernel boot. |
| 166 | |
| 167 | If you are unsure as to whether this is required, answer N. |
| 168 | |
| 169 | config LSM_MMAP_MIN_ADDR |
| 170 | int "Low address space for LSM to protect from user allocation" |
| 171 | depends on SECURITY && SECURITY_SELINUX |
| 172 | default 32768 if ARM || (ARM64 && COMPAT) |
| 173 | default 65536 |
| 174 | help |
| 175 | This is the portion of low virtual memory which should be protected |
| 176 | from userspace allocation. Keeping a user from writing to low pages |
| 177 | can help reduce the impact of kernel NULL pointer bugs. |
| 178 | |
| 179 | For most ia64, ppc64 and x86 users with lots of address space |
| 180 | a value of 65536 is reasonable and should cause no problems. |
| 181 | On arm and other archs it should not be higher than 32768. |
| 182 | Programs which use vm86 functionality or have some need to map |
| 183 | this low address space will need the permission specific to the |
| 184 | systems running LSM. |
| 185 | |
| 186 | config STATIC_USERMODEHELPER |
| 187 | bool "Force all usermode helper calls through a single binary" |
| 188 | help |
| 189 | By default, the kernel can call many different userspace |
| 190 | binary programs through the "usermode helper" kernel |
| 191 | interface. Some of these binaries are statically defined |
| 192 | either in the kernel code itself, or as a kernel configuration |
| 193 | option. However, some of these are dynamically created at |
| 194 | runtime, or can be modified after the kernel has started up. |
| 195 | To provide an additional layer of security, route all of these |
| 196 | calls through a single executable that can not have its name |
| 197 | changed. |
| 198 | |
| 199 | Note, it is up to this single binary to then call the relevant |
| 200 | "real" usermode helper binary, based on the first argument |
| 201 | passed to it. If desired, this program can filter and pick |
| 202 | and choose what real programs are called. |
| 203 | |
| 204 | If you wish for all usermode helper programs are to be |
| 205 | disabled, choose this option and then set |
| 206 | STATIC_USERMODEHELPER_PATH to an empty string. |
| 207 | |
| 208 | config STATIC_USERMODEHELPER_PATH |
| 209 | string "Path to the static usermode helper binary" |
| 210 | depends on STATIC_USERMODEHELPER |
| 211 | default "/sbin/usermode-helper" |
| 212 | help |
| 213 | The binary called by the kernel when any usermode helper |
| 214 | program is wish to be run. The "real" application's name will |
| 215 | be in the first argument passed to this program on the command |
| 216 | line. |
| 217 | |
| 218 | If you wish for all usermode helper programs to be disabled, |
| 219 | specify an empty string here (i.e. ""). |
| 220 | |
| 221 | source "security/selinux/Kconfig" |
| 222 | source "security/smack/Kconfig" |
| 223 | source "security/tomoyo/Kconfig" |
| 224 | source "security/apparmor/Kconfig" |
| 225 | source "security/loadpin/Kconfig" |
| 226 | source "security/yama/Kconfig" |
| 227 | source "security/safesetid/Kconfig" |
| 228 | source "security/lockdown/Kconfig" |
| 229 | source "security/landlock/Kconfig" |
| 230 | source "security/ipe/Kconfig" |
| 231 | |
| 232 | source "security/integrity/Kconfig" |
| 233 | |
| 234 | choice |
| 235 | prompt "First legacy 'major LSM' to be initialized" |
| 236 | default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX |
| 237 | default DEFAULT_SECURITY_SMACK if SECURITY_SMACK |
| 238 | default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO |
| 239 | default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR |
| 240 | default DEFAULT_SECURITY_DAC |
| 241 | |
| 242 | help |
| 243 | This choice is there only for converting CONFIG_DEFAULT_SECURITY |
| 244 | in old kernel configs to CONFIG_LSM in new kernel configs. Don't |
| 245 | change this choice unless you are creating a fresh kernel config, |
| 246 | for this choice will be ignored after CONFIG_LSM has been set. |
| 247 | |
| 248 | Selects the legacy "major security module" that will be |
| 249 | initialized first. Overridden by non-default CONFIG_LSM. |
| 250 | |
| 251 | config DEFAULT_SECURITY_SELINUX |
| 252 | bool "SELinux" if SECURITY_SELINUX=y |
| 253 | |
| 254 | config DEFAULT_SECURITY_SMACK |
| 255 | bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y |
| 256 | |
| 257 | config DEFAULT_SECURITY_TOMOYO |
| 258 | bool "TOMOYO" if SECURITY_TOMOYO=y |
| 259 | |
| 260 | config DEFAULT_SECURITY_APPARMOR |
| 261 | bool "AppArmor" if SECURITY_APPARMOR=y |
| 262 | |
| 263 | config DEFAULT_SECURITY_DAC |
| 264 | bool "Unix Discretionary Access Controls" |
| 265 | |
| 266 | endchoice |
| 267 | |
| 268 | config LSM |
| 269 | string "Ordered list of enabled LSMs" |
| 270 | depends on SECURITY |
| 271 | default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,ipe,bpf" if DEFAULT_SECURITY_SMACK |
| 272 | default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,ipe,bpf" if DEFAULT_SECURITY_APPARMOR |
| 273 | default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,ipe,bpf" if DEFAULT_SECURITY_TOMOYO |
| 274 | default "landlock,lockdown,yama,loadpin,safesetid,ipe,bpf" if DEFAULT_SECURITY_DAC |
| 275 | default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf" |
| 276 | help |
| 277 | A comma-separated list of LSMs, in initialization order. |
| 278 | Any LSMs left off this list, except for those with order |
| 279 | LSM_ORDER_FIRST and LSM_ORDER_LAST, which are always enabled |
| 280 | if selected in the kernel configuration, will be ignored. |
| 281 | This can be controlled at boot with the "lsm=" parameter. |
| 282 | |
| 283 | If unsure, leave this as the default. |
| 284 | |
| 285 | config SECURITY_COMMONCAP_KUNIT_TEST |
| 286 | bool "Build KUnit tests for commoncap" if !KUNIT_ALL_TESTS |
| 287 | depends on KUNIT=y && USER_NS |
| 288 | default KUNIT_ALL_TESTS |
| 289 | help |
| 290 | This builds the commoncap KUnit tests. |
| 291 | |
| 292 | KUnit tests run during boot and output the results to the debug log |
| 293 | in TAP format (https://testanything.org/). Only useful for kernel devs |
| 294 | running KUnit test harness and are not for inclusion into a |
| 295 | production build. |
| 296 | |
| 297 | For more information on KUnit and unit tests in general please refer |
| 298 | to the KUnit documentation in Documentation/dev-tools/kunit/. |
| 299 | |
| 300 | If unsure, say N. |
| 301 | |
| 302 | source "security/Kconfig.hardening" |
| 303 | |
| 304 | endmenu |
| 305 | |