Changes in Kconfig

5796d396 - mseal sysmap: kernel config and header change

Wed, 05 Mar 2025 02:17:05 +0000

mseal sysmap: kernel config and header changePatch series "mseal system mappings", v9.As discussed during mseal() upstream process [1], mseal() protects theVMAs of a given virtual memory range against modifications, such as theread/write (RW) and no-execute (NX) bits. For complete descriptions ofmemory sealing, please see mseal.rst [2].The mseal() is useful to mitigate memory corruption issues where acorrupted pointer is passed to a memory management system. For example,such an attacker primitive can break control-flow integrity guaranteessince read-only memory that is supposed to be trusted can become writableor .text pages can get remapped.The system mappings are readonly only, memory sealing can protect themfrom ever changing to writable or unmmap/remapped as different attributes.System mappings such as vdso, vvar, vvar_vclock, vectors (armcompat-mode), sigpage (arm compat-mode), are created by the kernel duringprogram initialization, and could be sealed after creation.Unlike the aforementioned mappings, the uprobe mapping is not establishedduring program startup. However, its lifetime is the same as theprocess's lifetime [3]. It could be sealed from creation.The vsyscall on x86-64 uses a special address (0xffffffffff600000), whichis outside the mm managed range. This means mprotect, munmap, and mremapwon't work on the vsyscall. Since sealing doesn't enhance the vsyscall'ssecurity, it is skipped in this patch. If we ever seal the vsyscall, itis probably only for decorative purpose, i.e. showing the 'sl' flag inthe /proc/pid/smaps. For this patch, it is ignored.It is important to note that the CHECKPOINT_RESTORE feature (CRIU) mayalter the system mappings during restore operations. UML(User Mode Linux)and gVisor, rr are also known to change the vdso/vvar mappings. Consequently, this feature cannot be universally enabled across allsystems. As such, CONFIG_MSEAL_SYSTEM_MAPPINGS is disabled by default.To support mseal of system mappings, architectures must defineCONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS and update their specialmappings calls to pass mseal flag. Additionally, architectures mustconfirm they do not unmap/remap system mappings during the processlifetime. The existence of this flag for an architecture implies that itdoes not require the remapping of thest system mappings during processlifetime, so sealing these mappings is safe from a kernel perspective.This version covers x86-64 and arm64 archiecture as minimum viable feature.While no specific CPU hardware features are required for enable thisfeature on an archiecture, memory sealing requires a 64-bit kernel. Otherarchitectures can choose whether or not to adopt this feature. Currently,I'm not aware of any instances in the kernel code that activelymunmap/mremap a system mapping without a request from userspace. The PPCdoes call munmap when _install_special_mapping fails for vdso; however,it's uncertain if this will ever fail for PPC - this needs to beinvestigated by PPC in the future [4]. The UML kernel can add thissupport when KUnit tests require it [5].In this version, we've improved the handling of system mapping sealingfrom previous versions, instead of modifying the _install_special_mappingfunction itself, which would affect all architectures, we now call_install_special_mapping with a sealing flag only within the specificarchitecture that requires it. This targeted approach offers two keyadvantages: 1) It limits the code change's impact to the necessaryarchitectures, and 2) It aligns with the software architecture by keepingthe core memory management within the mm layer, while delegating thedecision of sealing system mappings to the individual architecture, whichis particularly relevant since 32-bit architectures never require sealing.Prior to this patch series, we explored sealing special mappings fromuserspace using glibc's dynamic linker. This approach revealed severalissues:- The PT_LOAD header may report an incorrect length for vdso, (smaller than its actual size). The dynamic linker, which relies on PT_LOAD information to determine mapping size, would then split and partially seal the vdso mapping. Since each architecture has its own vdso/vvar code, fixing this in the kernel would require going through each archiecture. Our initial goal was to enable sealing readonly mappings, e.g. .text, across all architectures, sealing vdso from kernel since creation appears to be simpler than sealing vdso at glibc.- The [vvar] mapping header only contains address information, not length information. Similar issues might exist for other special mappings.- Mappings like uprobe are not covered by the dynamic linker, and there is no effective solution for them.This feature's security enhancements will benefit ChromeOS, Android, andother high security systems.Testing:This feature was tested on ChromeOS and Android for both x86-64 and ARM64.- Enable sealing and verify vdso/vvar, sigpage, vector are sealed properly, i.e. "sl" shown in the smaps for those mappings, and mremap is blocked.- Passing various automation tests (e.g. pre-checkin) on ChromeOS and Android to ensure the sealing doesn't affect the functionality of Chromebook and Android phone.I also tested the feature on Ubuntu on x86-64:- With config disabled, vdso/vvar is not sealed,- with config enabled, vdso/vvar is sealed, and booting up Ubuntu is OK, normal operations such as browsing the web, open/edit doc are OK.Link: https://lore.kernel.org/all/20240415163527.626541-1-jeffxu@chromium.org/ [1]Link: Documentation/userspace-api/mseal.rst [2]Link: https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/ [3]Link: https://lore.kernel.org/all/CABi2SkV6JJwJeviDLsq9N4ONvQ=EFANsiWkgiEOjyT9TQSt+HA@mail.gmail.com/ [4]Link: https://lore.kernel.org/all/202502251035.239B85A93@keescook/ [5]This patch (of 7):Provide infrastructure to mseal system mappings. Establish two kernelconfigs (CONFIG_MSEAL_SYSTEM_MAPPINGS,ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP macro for futurepatches.Link: https://lkml.kernel.org/r/20250305021711.3867874-1-jeffxu@google.comLink: https://lkml.kernel.org/r/20250305021711.3867874-2-jeffxu@google.comSigned-off-by: Jeff Xu Reviewed-by: Kees Cook Reviewed-by: Liam R. Howlett Reviewed-by: Lorenzo Stoakes Cc: Adhemerval Zanella Cc: Alexander Mikhalitsyn Cc: Alexey Dobriyan Cc: Andrei Vagin Cc: Anna-Maria Behnsen Cc: Ard Biesheuvel Cc: Benjamin Berg Cc: Christoph Hellwig Cc: Dave Hansen Cc: David Rientjes Cc: David S. Miller Cc: Elliot Hughes Cc: Florian Faineli Cc: Greg Ungerer Cc: Guenter Roeck Cc: Heiko Carstens Cc: Helge Deller Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>Cc: Ingo Molnar Cc: Jann Horn Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Jorge Lucangeli Obes Cc: Linus Waleij Cc: Mark Rutland Cc: Matthew Wilcow (Oracle) Cc: Michael Ellerman Cc: Michal Hocko Cc: Miguel Ojeda Cc: Mike Rapoport Cc: Oleg Nesterov Cc: Pedro Falcato Cc: Peter Xu Cc: Randy Dunlap Cc: Stephen Röttger Cc: Thomas Weißschuh Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux-6.15/security/Kconfig

ca758b14 - fortify: Move FORTIFY_SOURCE under 'Kernel hardening options'

Thu, 23 Jan 2025 22:11:15 +0000

fortify: Move FORTIFY_SOURCE under 'Kernel hardening options'FORTIFY_SOURCE is a hardening option both at build and runtime. Moveit under 'Kernel hardening options'.Signed-off-by: Mel Gorman Acked-by: Paul Moore Link: https://lore.kernel.org/r/20250123221115.19722-5-mgorman@techsingularity.netSigned-off-by: Kees Cook List of files: /linux-6.15/security/Kconfig

f4d4e8b9 - mm: security: Move hardened usercopy under 'Kernel hardening options'

Thu, 23 Jan 2025 22:11:12 +0000

mm: security: Move hardened usercopy under 'Kernel hardening options'There is a submenu for 'Kernel hardening options' under "Security".Move HARDENED_USERCOPY under the hardening options as it is clearlyrelated.Signed-off-by: Mel Gorman Acked-by: Paul Moore Link: https://lore.kernel.org/r/20250123221115.19722-2-mgorman@techsingularity.netSigned-off-by: Kees Cook List of files: /linux-6.15/security/Kconfig

7ccbe076 - lsm: Only build lsm_audit.c if CONFIG_SECURITY and CONFIG_AUDIT are set

Fri, 22 Nov 2024 14:33:31 +0000

lsm: Only build lsm_audit.c if CONFIG_SECURITY and CONFIG_AUDIT are setWhen CONFIG_AUDIT is set, its CONFIG_NET dependency is also set, and thedev_get_by_index and init_net symbols (used by dump_common_audit_data)are found by the linker. dump_common_audit_data() should then failed tobuild when CONFIG_NET is not set. However, because the compiler issmart, it knows that audit_log_start() always return NULL when!CONFIG_AUDIT, and it doesn't build the body of common_lsm_audit(). Asa side effect, dump_common_audit_data() is not built and the linkerdoesn't error out because of missing symbols.Let's only build lsm_audit.o when CONFIG_SECURITY and CONFIG_AUDIT areboth set, which is checked with the new CONFIG_HAS_SECURITY_AUDIT.ipv4_skb_to_auditdata() and ipv6_skb_to_auditdata() are only used bySmack if CONFIG_AUDIT is set, so they don't need fake implementations.Because common_lsm_audit() is used in multiple places withoutCONFIG_AUDIT checks, add a fake implementation.Link: https://lore.kernel.org/r/20241122143353.59367-2-mic@digikod.netCc: Casey Schaufler Cc: James Morris Cc: Paul Moore Cc: Serge E. Hallyn Signed-off-by: Mickaël Salaün Signed-off-by: Paul Moore List of files: /linux-6.15/security/Kconfig

41e8149c - proc: add config & param to block forcing mem writes

Fri, 02 Aug 2024 08:02:25 +0000

proc: add config & param to block forcing mem writesThis adds a Kconfig option and boot param to allow removingthe FOLL_FORCE flag from /proc/pid/mem write calls becauseit can be abused.The traditional forcing behavior is kept as default becauseit can break GDB and some other use cases.Previously we tried a more sophisticated approach allowingdistributions to fine-tune /proc/pid/mem behavior, howeverthat got NAK-ed by Linus [1], who prefers this simplerapproach with semantics also easier to understand for users.Link: https://lore.kernel.org/lkml/CAHk-=wiGWLChxYmUA5HrT5aopZrB7_2VTa0NLZcxORgkUe5tEQ@mail.gmail.com/ [1]Cc: Doug Anderson Cc: Jeff Xu Cc: Jann Horn Cc: Kees Cook Cc: Ard Biesheuvel Cc: Christian Brauner Suggested-by: Linus Torvalds Signed-off-by: Linus Torvalds Signed-off-by: Adrian Ratiu Link: https://lore.kernel.org/r/20240802080225.89408-1-adrian.ratiu@collabora.comSigned-off-by: Christian Brauner List of files: /linux-6.15/security/Kconfig

03115077 - lsm: add IPE lsm

Sat, 03 Aug 2024 06:08:15 +0000

lsm: add IPE lsmIntegrity Policy Enforcement (IPE) is an LSM that provides ancomplimentary approach to Mandatory Access Control than existing LSMstoday.Existing LSMs have centered around the concept of access to a resourceshould be controlled by the current user's credentials. IPE's approach,is that access to a resource should be controlled by the system's trustof a current resource.The basis of this approach is defining a global policy to specify whichresource can be trusted.Signed-off-by: Deven Bowers Signed-off-by: Fan Wu [PM: subject line tweak]Signed-off-by: Paul Moore List of files: /linux-6.15/security/Kconfig

7d354f49 - fortify: drop Clang version check for 12.0.1 or newer

Thu, 25 Jan 2024 22:55:15 +0000

fortify: drop Clang version check for 12.0.1 or newerNow that the minimum supported version of LLVM for building the kernel hasbeen bumped to 13.0.1, this condition is always true, as the build willfail during the configuration stage for older LLVM versions. Remove it.Link: https://lkml.kernel.org/r/20240125-bump-min-llvm-ver-to-13-0-1-v1-9-f5ff9bda41c5@kernel.orgSigned-off-by: Nathan Chancellor Reviewed-by: Kees Cook Cc: Albert Ou Cc: "Aneesh Kumar K.V (IBM)" Cc: Ard Biesheuvel Cc: Borislav Petkov (AMD) Cc: Catalin Marinas Cc: Conor Dooley Cc: Dave Hansen Cc: Ingo Molnar Cc: Mark Rutland Cc: Masahiro Yamada Cc: Michael Ellerman Cc: "Naveen N. Rao" Cc: Nicholas Piggin Cc: Nicolas Schier Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/security/Kconfig

2947a456 - treewide: update LLVM Bugzilla links

Tue, 09 Jan 2024 22:16:31 +0000

treewide: update LLVM Bugzilla linksLLVM moved their issue tracker from their own Bugzilla instance to GitHubissues. While all of the links are still valid, they may not necessarilyshow the most up to date information around the issues, as all updateswill occur on GitHub, not Bugzilla.Another complication is that the Bugzilla issue number is not always thesame as the GitHub issue number. Thankfully, LLVM maintains this mappingthrough two shortlinks: https://llvm.org/bz -> https://bugs.llvm.org/show_bug.cgi?id= https://llvm.org/pr -> https://github.com/llvm/llvm-project/issues/Switch all "https://bugs.llvm.org/show_bug.cgi?id=" links to the"https://llvm.org/pr" shortlink so that the links show the most up todate information. Each migrated issue links back to the Bugzilla entry,so there should be no loss of fidelity of information here.Link: https://lkml.kernel.org/r/20240109-update-llvm-links-v1-3-eb09b59db071@kernel.orgSigned-off-by: Nathan Chancellor Reviewed-by: Kees Cook Acked-by: Fangrui Song Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Mykola Lysenko Signed-off-by: Andrew Morton List of files: /linux-6.15/security/Kconfig

d2e527f0 - mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATOR

Tue, 23 May 2023 07:26:35 +0000

mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATORWith SLOB removed, both remaining allocators support hardened usercopy,so remove the config and associated #ifdef.Signed-off-by: Vlastimil Babka Reviewed-by: David Hildenbrand Reviewed-by: Lorenzo Stoakes Reviewed-by: Kees Cook Acked-by: David Rientjes Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> List of files: /linux-6.15/security/Kconfig

ff61f079 - docs: move x86 documentation into Documentation/arch/

Tue, 14 Mar 2023 23:06:44 +0000

docs: move x86 documentation into Documentation/arch/Move the x86 documentation under Documentation/arch/ as a way of cleaningup the top-level directory and making the structure of our docs moreclosely match the structure of the source directories it describes.All in-kernel references to the old paths have been updated.Acked-by: Dave Hansen Cc: linux-arch@vger.kernel.orgCc: x86@kernel.orgCc: Borislav Petkov Cc: Thomas Gleixner Link: https://lore.kernel.org/lkml/20230315211523.108836-1-corbet@lwn.net/Signed-off-by: Jonathan Corbet List of files: /linux-6.15/security/Kconfig

f22f9aaf - selinux: remove the runtime disable functionality

Fri, 17 Mar 2023 16:43:07 +0000

selinux: remove the runtime disable functionalityAfter working with the larger SELinux-based distros for severalyears, we're finally at a place where we can disable the SELinuxruntime disable functionality. The existing kernel deprecationnotice explains the functionality and why we want to remove it: The selinuxfs "disable" node allows SELinux to be disabled at runtime prior to a policy being loaded into the kernel. If disabled via this mechanism, SELinux will remain disabled until the system is rebooted. The preferred method of disabling SELinux is via the "selinux=0" boot parameter, but the selinuxfs "disable" node was created to make it easier for systems with primitive bootloaders that did not allow for easy modification of the kernel command line. Unfortunately, allowing for SELinux to be disabled at runtime makes it difficult to secure the kernel's LSM hooks using the "__ro_after_init" feature.It is that last sentence, mentioning the '__ro_after_init' hardening,which is the real motivation for this change, and if you look at thediffstat you'll see that the impact of this patch reaches across allthe different LSMs, helping prevent tampering at the LSM hook level.From a SELinux perspective, it is important to note that if youcontinue to disable SELinux via "/etc/selinux/config" it may appearthat SELinux is disabled, but it is simply in an uninitialized state.If you load a policy with `load_policy -i`, you will see SELinuxcome alive just as if you had loaded the policy during early-boot.It is also worth noting that the "/sys/fs/selinux/disable" file isalways writable now, regardless of the Kconfig settings, but writingto the file has no effect on the system, other than to display anerror on the console if a non-zero/true value is written.Finally, in the several years where we have been working ondeprecating this functionality, there has only been one instance ofsomeone mentioning any user visible breakage. In this particularcase it was an individual's kernel test system, and the workarounddocumented in the deprecation notice ("selinux=0" on the kernelcommand line) resolved the issue without problem.Acked-by: Casey Schaufler Signed-off-by: Paul Moore List of files: /linux-6.15/security/Kconfig

b9b8701b - security: Remove integrity from the LSM list in Kconfig

Fri, 10 Mar 2023 08:54:01 +0000

security: Remove integrity from the LSM list in KconfigRemove 'integrity' from the list of LSMs in Kconfig, as it is no longernecessary. Since the recent change (set order to LSM_ORDER_LAST), the'integrity' LSM is always enabled (if selected in the kernelconfiguration).Signed-off-by: Roberto Sassu Acked-by: Mimi Zohar Signed-off-by: Paul Moore List of files: /linux-6.15/security/Kconfig

f43b9876 - x86/retbleed: Add fine grained Kconfig knobs

Mon, 27 Jun 2022 22:21:17 +0000

x86/retbleed: Add fine grained Kconfig knobsDo fine-grained Kconfig for all the various retbleed parts.NOTE: if your compiler doesn't support return thunks this willsilently 'upgrade' your mitigation to IBPB, you might not like this.Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov List of files: /linux-6.15/security/Kconfig

1109a5d9 - usercopy: Remove HARDENED_USERCOPY_PAGESPAN

Mon, 10 Jan 2022 23:15:30 +0000

usercopy: Remove HARDENED_USERCOPY_PAGESPANThere isn't enough information to make this a useful check any more;the useful parts of it were moved in earlier patches, so remove thisset of checks now.Signed-off-by: Matthew Wilcox (Oracle) Acked-by: Kees Cook Reviewed-by: David Hildenbrand Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220110231530.665970-5-willy@infradead.org List of files: /linux-6.15/security/Kconfig

ef3e787c - usercopy: Disable CONFIG_HARDENED_USERCOPY_PAGESPAN

Thu, 24 Mar 2022 22:57:25 +0000

usercopy: Disable CONFIG_HARDENED_USERCOPY_PAGESPANCONFIG_HARDENED_USERCOPY_PAGESPAN has been mostly broken for a while,and it has become hard to ignore with some recent scsi changes[1].While there is a more complete series to replace it with better checks[2],it should have more soak time in -next. Instead, disable the config now,with the expectation that it will be fully replaced in the next kernelrelease.[1] https://lore.kernel.org/lkml/20220324064846.GA12961@lst.de/[2] https://lore.kernel.org/linux-hardening/20220110231530.665970-1-willy@infradead.org/Suggested-by: Christoph Hellwig Cc: "Matthew Wilcox (Oracle)" Signed-off-by: Kees Cook List of files: /linux-6.15/security/Kconfig

281d0c96 - fortify: Add Clang support

Tue, 08 Feb 2022 22:53:50 +0000

fortify: Add Clang supportEnable FORTIFY_SOURCE support for Clang:Use the new __pass_object_size and __overloadable attributes so thatClang will have appropriate visibility into argument sizes such that__builtin_object_size(p, 1) will behave correctly. Additional detailsavailable here: https://github.com/llvm/llvm-project/issues/53516 https://github.com/ClangBuiltLinux/linux/issues/1401A bug with __builtin_constant_p() of globally defined variables wasfixed in Clang 13 (and backported to 12.0.1), so FORTIFY support mustdepend on that version or later. Additional details here: https://bugs.llvm.org/show_bug.cgi?id=41459 commit a52f8a59aef4 ("fortify: Explicitly disable Clang support")A bug with Clang's -mregparm=3 and -m32 makes some builtins unusable,so removing -ffreestanding (to gain the needed libcall optimizationswith Clang) cannot be done. Without the libcall optimizations, Clangcannot provide appropriate FORTIFY coverage, so it must be disabledfor CONFIG_X86_32. Additional details here; https://github.com/llvm/llvm-project/issues/53645Cc: Miguel Ojeda Cc: Nick Desaulniers Cc: Nathan Chancellor Cc: George Burgess IV Cc: llvm@lists.linux.devSigned-off-by: Kees Cook Reviewed-by: Nick Desaulniers Link: https://lore.kernel.org/r/20220208225350.1331628-9-keescook@chromium.org List of files: /linux-6.15/security/Kconfig

53944f17 - mm: remove HARDENED_USERCOPY_FALLBACK

Fri, 05 Nov 2021 20:45:18 +0000

mm: remove HARDENED_USERCOPY_FALLBACKThis has served its purpose and is no longer used. All usercopyviolations appear to have been handled by now, any remaining instances(or new bugs) will cause copies to be rejected.This isn't a direct revert of commit 2d891fbc3bb6 ("usercopy: Allowstrict enforcement of whitelists"); since usercopy_fallback iseffectively 0, the fallback handling is removed too.This also removes the usercopy_fallback module parameter on slab_common.Link: https://github.com/KSPP/linux/issues/153Link: https://lkml.kernel.org/r/20210921061149.1091163-1-steve@sk2.orgSigned-off-by: Stephen Kitt Suggested-by: Kees Cook Acked-by: Kees Cook Reviewed-by: Joel Stanley [defconfig change]Acked-by: David Rientjes Cc: Christoph Lameter Cc: Pekka Enberg Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: James Morris Cc: "Serge E . Hallyn" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/security/Kconfig

a52f8a59 - fortify: Explicitly disable Clang support

Thu, 13 May 2021 04:51:10 +0000

fortify: Explicitly disable Clang supportClang has never correctly compiled the FORTIFY_SOURCE defenses due toa couple bugs: Eliding inlines with matching __builtin_* names https://bugs.llvm.org/show_bug.cgi?id=50322 Incorrect __builtin_constant_p() of some globals https://bugs.llvm.org/show_bug.cgi?id=41459In the process of making improvements to the FORTIFY_SOURCE defenses, thefirst (silent) bug (coincidentally) becomes worked around, but exposesthe latter which breaks the build. As such, Clang must not be used withCONFIG_FORTIFY_SOURCE until at least latter bug is fixed (in Clang 13),and the fortify routines have been rearranged.Update the Kconfig to reflect the reality of the current situation.Signed-off-by: Kees Cook Acked-by: Nick Desaulniers Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com List of files: /linux-6.15/security/Kconfig

385975dc - landlock: Set up the security framework and manage credentials

Thu, 22 Apr 2021 15:41:13 +0000

landlock: Set up the security framework and manage credentialsProcess's credentials point to a Landlock domain, which is underneathimplemented with a ruleset. In the following commits, this domain isused to check and enforce the ptrace and filesystem security policies.A domain is inherited from a parent to its child the same way a threadinherits a seccomp policy.Cc: James Morris Signed-off-by: Mickaël Salaün Reviewed-by: Jann Horn Acked-by: Serge Hallyn Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20210422154123.13086-4-mic@digikod.netSigned-off-by: James Morris List of files: /linux-6.15/security/Kconfig

90945448 - landlock: Add object management

Thu, 22 Apr 2021 15:41:11 +0000

landlock: Add object managementA Landlock object enables to identify a kernel object (e.g. an inode).A Landlock rule is a set of access rights allowed on an object. Rulesare grouped in rulesets that may be tied to a set of processes (i.e.subjects) to enforce a scoped access-control (i.e. a domain).Because Landlock's goal is to empower any process (especiallyunprivileged ones) to sandbox themselves, we cannot rely on asystem-wide object identification such as file extended attributes.Indeed, we need innocuous, composable and modular access-controls.The main challenge with these constraints is to identify kernel objectswhile this identification is useful (i.e. when a security policy makesuse of this object). But this identification data should be freed onceno policy is using it. This ephemeral tagging should not and may not bewritten in the filesystem. We then need to manage the lifetime of arule according to the lifetime of its objects. To avoid a global lock,this implementation make use of RCU and counters to safely referenceobjects.A following commit uses this generic object management for inodes.Cc: James Morris Signed-off-by: Mickaël Salaün Reviewed-by: Jann Horn Acked-by: Serge Hallyn Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20210422154123.13086-2-mic@digikod.netSigned-off-by: James Morris List of files: /linux-6.15/security/Kconfig