a430d95c5e
-----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAmbiGGAUHHBhdWxAcGF1 bC1tb29yZS5jb20ACgkQ6iDy2pc3iXPU8BAA1+A15pmS34I9pq7c8TmRz3rNEs/a zrW1aWJ0X/+axNS7sW3Pwtt1EKuaOhskKU8gNSieRhljC8rgXIVjZzLw6Atgcr5k upulGbU9TXyVisYN+PWv9/84ito6/nYsKb7Mg3nUVsdodtIFVnsk1fxYLPHQEBig Pl3i26U3VqH93Kz0W5vs/QR2uduPB8ZyscdTgcbrY9Vv1Y7IDZ2g9QsJVKLvbQKL qcPK1JkHa+sBPJxDqS9A40zgbLbdPQgWQzsXX3dz822w1Ga7FIHSqxMBA6HwHZ+L kV4P58wVfavhwt/cQSKMWI/yiGPMMd0B6yD+m8ojOvGfOfRCWxGMmEMqHNuZ3m7k Bfll5ZgZTY8phUUhiNf3nxO3F3MM/5bHdhPOj3RReqbAbS6uWr4/fThPDYY/zIo6 NCY3HGxx3Ae64uQ01gC2p/czC50jDsMwlbXiZbrgdBhjBm/CVk5ozb80mLVcGrLB +6XMzzSbC8IaNAH2fDmUJ2ABdwyNPgsSOTGZVzIanpxu1SU2/yk3SMxkp8fv5s36 wLeODUVcLgsjVV538Mkm6PGTE4TlXaH9yi6apMyJAGp0vPYx5c3Xxk2y5A5cur5p hcrbDiX2QgeqFbwsz36incmPmbef2NU2c8feR8XLtPJuwNIeRcMSje0pnkaFlRmb TAUJ1sDQAzZ8Fy0= =HIAO -----END PGP SIGNATURE----- Merge tag 'lsm-pr-20240911' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm Pull lsm updates from Paul Moore: - Move the LSM framework to static calls This transitions the vast majority of the LSM callbacks into static calls. Those callbacks which haven't been converted were left as-is due to the general ugliness of the changes required to support the static call conversion; we can revisit those callbacks at a future date. - Add the Integrity Policy Enforcement (IPE) LSM This adds a new LSM, Integrity Policy Enforcement (IPE). There is plenty of documentation about IPE in this patches, so I'll refrain from going into too much detail here, but the basic motivation behind IPE is to provide a mechanism such that administrators can restrict execution to only those binaries which come from integrity protected storage, e.g. a dm-verity protected filesystem. You will notice that IPE requires additional LSM hooks in the initramfs, dm-verity, and fs-verity code, with the associated patches carrying ACK/review tags from the associated maintainers. We couldn't find an obvious maintainer for the initramfs code, but the IPE patchset has been widely posted over several years. Both Deven Bowers and Fan Wu have contributed to IPE's development over the past several years, with Fan Wu agreeing to serve as the IPE maintainer moving forward. Once IPE is accepted into your tree, I'll start working with Fan to ensure he has the necessary accounts, keys, etc. so that he can start submitting IPE pull requests to you directly during the next merge window. - Move the lifecycle management of the LSM blobs to the LSM framework Management of the LSM blobs (the LSM state buffers attached to various kernel structs, typically via a void pointer named "security" or similar) has been mixed, some blobs were allocated/managed by individual LSMs, others were managed by the LSM framework itself. Starting with this pull we move management of all the LSM blobs, minus the XFRM blob, into the framework itself, improving consistency across LSMs, and reducing the amount of duplicated code across LSMs. Due to some additional work required to migrate the XFRM blob, it has been left as a todo item for a later date; from a practical standpoint this omission should have little impact as only SELinux provides a XFRM LSM implementation. - Fix problems with the LSM's handling of F_SETOWN The LSM hook for the fcntl(F_SETOWN) operation had a couple of problems: it was racy with itself, and it was disconnected from the associated DAC related logic in such a way that the LSM state could be updated in cases where the DAC state would not. We fix both of these problems by moving the security_file_set_fowner() hook into the same section of code where the DAC attributes are updated. Not only does this resolve the DAC/LSM synchronization issue, but as that code block is protected by a lock, it also resolve the race condition. - Fix potential problems with the security_inode_free() LSM hook Due to use of RCU to protect inodes and the placement of the LSM hook associated with freeing the inode, there is a bit of a challenge when it comes to managing any LSM state associated with an inode. The VFS folks are not open to relocating the LSM hook so we have to get creative when it comes to releasing an inode's LSM state. Traditionally we have used a single LSM callback within the hook that is triggered when the inode is "marked for death", but not actually released due to RCU. Unfortunately, this causes problems for LSMs which want to take an action when the inode's associated LSM state is actually released; so we add an additional LSM callback, inode_free_security_rcu(), that is called when the inode's LSM state is released in the RCU free callback. - Refactor two LSM hooks to better fit the LSM return value patterns The vast majority of the LSM hooks follow the "return 0 on success, negative values on failure" pattern, however, there are a small handful that have unique return value behaviors which has caused confusion in the past and makes it difficult for the BPF verifier to properly vet BPF LSM programs. This includes patches to convert two of these"special" LSM hooks to the common 0/-ERRNO pattern. - Various cleanups and improvements A handful of patches to remove redundant code, better leverage the IS_ERR_OR_NULL() helper, add missing "static" markings, and do some minor style fixups. * tag 'lsm-pr-20240911' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: (40 commits) security: Update file_set_fowner documentation fs: Fix file_set_fowner LSM hook inconsistencies lsm: Use IS_ERR_OR_NULL() helper function lsm: remove LSM_COUNT and LSM_CONFIG_COUNT ipe: Remove duplicated include in ipe.c lsm: replace indirect LSM hook calls with static calls lsm: count the LSMs enabled at compile time kernel: Add helper macros for loop unrolling init/main.c: Initialize early LSMs after arch code, static keys and calls. MAINTAINERS: add IPE entry with Fan Wu as maintainer documentation: add IPE documentation ipe: kunit test for parser scripts: add boot policy generation program ipe: enable support for fs-verity as a trust provider fsverity: expose verified fsverity built-in signatures to LSMs lsm: add security_inode_setintegrity() hook ipe: add support for dm-verity as a trust provider dm-verity: expose root hash digest and signature data to LSMs block,lsm: add LSM blob and new LSM hooks for block devices ipe: add permissive toggle ...
10 KiB
SPDX-License-Identifier: GPL-2.0-only
Security configuration
menu "Security options"
source "security/keys/Kconfig"
config SECURITY_DMESG_RESTRICT bool "Restrict unprivileged access to the kernel syslog" default n help This enforces restrictions on unprivileged users reading the kernel syslog via dmesg(8).
If this option is not selected, no restrictions will be enforced
unless the dmesg_restrict sysctl is explicitly set to (1).
If you are unsure how to answer this question, answer N.
choice prompt "Allow /proc/pid/mem access override" default PROC_MEM_ALWAYS_FORCE help Traditionally /proc/pid/mem allows users to override memory permissions for users like ptrace, assuming they have ptrace capability.
This allows people to limit that - either never override, or
require actual active ptrace attachment.
Defaults to the traditional behavior (for now)
config PROC_MEM_ALWAYS_FORCE bool "Traditional /proc/pid/mem behavior" help This allows /proc/pid/mem accesses to override memory mapping permissions if you have ptrace access rights.
config PROC_MEM_FORCE_PTRACE bool "Require active ptrace() use for access override" help This allows /proc/pid/mem accesses to override memory mapping permissions for active ptracers like gdb.
config PROC_MEM_NO_FORCE bool "Never" help Never override memory mapping permissions
endchoice
config SECURITY bool "Enable different security models" depends on SYSFS depends on MULTIUSER help This allows you to choose different security modules to be configured into your kernel.
If this option is not selected, the default Linux security
model will be used.
If you are unsure how to answer this question, answer N.
config SECURITYFS bool "Enable the securityfs filesystem" help This will build the securityfs filesystem. It is currently used by various security modules (AppArmor, IMA, SafeSetID, TOMOYO, TPM).
If you are unsure how to answer this question, answer N.
config SECURITY_NETWORK bool "Socket and Networking Security Hooks" depends on SECURITY help This enables the socket and networking security hooks. If enabled, a security module can use these hooks to implement socket and networking access controls. If you are unsure how to answer this question, answer N.
config SECURITY_INFINIBAND bool "Infiniband Security Hooks" depends on SECURITY && INFINIBAND help This enables the Infiniband security hooks. If enabled, a security module can use these hooks to implement Infiniband access controls. If you are unsure how to answer this question, answer N.
config SECURITY_NETWORK_XFRM bool "XFRM (IPSec) Networking Security Hooks" depends on XFRM && SECURITY_NETWORK help This enables the XFRM (IPSec) networking security hooks. If enabled, a security module can use these hooks to implement per-packet access controls based on labels derived from IPSec policy. Non-IPSec communications are designated as unlabelled, and only sockets authorized to communicate unlabelled data can send without using IPSec. If you are unsure how to answer this question, answer N.
config SECURITY_PATH bool "Security hooks for pathname based access control" depends on SECURITY help This enables the security hooks for pathname based access control. If enabled, a security module can use these hooks to implement pathname based access controls. If you are unsure how to answer this question, answer N.
config INTEL_TXT bool "Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)" depends on HAVE_INTEL_TXT help This option enables support for booting the kernel with the Trusted Boot (tboot) module. This will utilize Intel(R) Trusted Execution Technology to perform a measured launch of the kernel. If the system does not support Intel(R) TXT, this will have no effect.
Intel TXT will provide higher assurance of system configuration and
initial state as well as data reset protection. This is used to
create a robust initial kernel measurement and verification, which
helps to ensure that kernel security mechanisms are functioning
correctly. This level of protection requires a root of trust outside
of the kernel itself.
Intel TXT also helps solve real end user concerns about having
confidence that their hardware is running the VMM or kernel that
it was configured with, especially since they may be responsible for
providing such assurances to VMs and services running on it.
See <https://www.intel.com/technology/security/> for more information
about Intel(R) TXT.
See <http://tboot.sourceforge.net> for more information about tboot.
See Documentation/arch/x86/intel_txt.rst for a description of how to enable
Intel TXT support in a kernel boot.
If you are unsure as to whether this is required, answer N.
config LSM_MMAP_MIN_ADDR int "Low address space for LSM to protect from user allocation" depends on SECURITY && SECURITY_SELINUX default 32768 if ARM || (ARM64 && COMPAT) default 65536 help This is the portion of low virtual memory which should be protected from userspace allocation. Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs.
For most ia64, ppc64 and x86 users with lots of address space
a value of 65536 is reasonable and should cause no problems.
On arm and other archs it should not be higher than 32768.
Programs which use vm86 functionality or have some need to map
this low address space will need the permission specific to the
systems running LSM.
config HARDENED_USERCOPY bool "Harden memory copies between kernel and userspace" imply STRICT_DEVMEM help This option checks for obviously wrong memory regions when copying memory to/from the kernel (via copy_to_user() and copy_from_user() functions) by rejecting memory ranges that are larger than the specified heap object, span multiple separately allocated pages, are not on the process stack, or are part of the kernel text. This prevents entire classes of heap overflow exploits and similar kernel memory exposures.
config FORTIFY_SOURCE bool "Harden common str/mem functions against buffer overflows" depends on ARCH_HAS_FORTIFY_SOURCE # https://github.com/llvm/llvm-project/issues/53645 depends on !CC_IS_CLANG || !X86_32 help Detect overflows of buffers in common string and memory functions where the compiler can determine and validate the buffer sizes.
config STATIC_USERMODEHELPER bool "Force all usermode helper calls through a single binary" help By default, the kernel can call many different userspace binary programs through the "usermode helper" kernel interface. Some of these binaries are statically defined either in the kernel code itself, or as a kernel configuration option. However, some of these are dynamically created at runtime, or can be modified after the kernel has started up. To provide an additional layer of security, route all of these calls through a single executable that can not have its name changed.
Note, it is up to this single binary to then call the relevant
"real" usermode helper binary, based on the first argument
passed to it. If desired, this program can filter and pick
and choose what real programs are called.
If you wish for all usermode helper programs are to be
disabled, choose this option and then set
STATIC_USERMODEHELPER_PATH to an empty string.
config STATIC_USERMODEHELPER_PATH string "Path to the static usermode helper binary" depends on STATIC_USERMODEHELPER default "/sbin/usermode-helper" help The binary called by the kernel when any usermode helper program is wish to be run. The "real" application's name will be in the first argument passed to this program on the command line.
If you wish for all usermode helper programs to be disabled,
specify an empty string here (i.e. "").
source "security/selinux/Kconfig" source "security/smack/Kconfig" source "security/tomoyo/Kconfig" source "security/apparmor/Kconfig" source "security/loadpin/Kconfig" source "security/yama/Kconfig" source "security/safesetid/Kconfig" source "security/lockdown/Kconfig" source "security/landlock/Kconfig" source "security/ipe/Kconfig"
source "security/integrity/Kconfig"
choice prompt "First legacy 'major LSM' to be initialized" default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX default DEFAULT_SECURITY_SMACK if SECURITY_SMACK default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR default DEFAULT_SECURITY_DAC
help
This choice is there only for converting CONFIG_DEFAULT_SECURITY
in old kernel configs to CONFIG_LSM in new kernel configs. Don't
change this choice unless you are creating a fresh kernel config,
for this choice will be ignored after CONFIG_LSM has been set.
Selects the legacy "major security module" that will be
initialized first. Overridden by non-default CONFIG_LSM.
config DEFAULT_SECURITY_SELINUX
bool "SELinux" if SECURITY_SELINUX=y
config DEFAULT_SECURITY_SMACK
bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
config DEFAULT_SECURITY_TOMOYO
bool "TOMOYO" if SECURITY_TOMOYO=y
config DEFAULT_SECURITY_APPARMOR
bool "AppArmor" if SECURITY_APPARMOR=y
config DEFAULT_SECURITY_DAC
bool "Unix Discretionary Access Controls"
endchoice
config LSM string "Ordered list of enabled LSMs" default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,ipe,bpf" if DEFAULT_SECURITY_SMACK default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,ipe,bpf" if DEFAULT_SECURITY_APPARMOR default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,ipe,bpf" if DEFAULT_SECURITY_TOMOYO default "landlock,lockdown,yama,loadpin,safesetid,ipe,bpf" if DEFAULT_SECURITY_DAC default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf" help A comma-separated list of LSMs, in initialization order. Any LSMs left off this list, except for those with order LSM_ORDER_FIRST and LSM_ORDER_LAST, which are always enabled if selected in the kernel configuration, will be ignored. This can be controlled at boot with the "lsm=" parameter.
If unsure, leave this as the default.
source "security/Kconfig.hardening"
endmenu