#
7d354f49 |
| 25-Jan-2024 |
Nathan Chancellor <nathan@kernel.org> |
fortify: drop Clang version check for 12.0.1 or newer
Now that the minimum supported version of LLVM for building the kernel has been bumped to 13.0.1, this condition is always true, as the build wi
fortify: drop Clang version check for 12.0.1 or newer
Now that the minimum supported version of LLVM for building the kernel has been bumped to 13.0.1, this condition is always true, as the build will fail 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.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: "Aneesh Kumar K.V (IBM)" <aneesh.kumar@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Conor Dooley <conor@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
2947a456 |
| 09-Jan-2024 |
Nathan Chancellor <nathan@kernel.org> |
treewide: update LLVM Bugzilla links
LLVM moved their issue tracker from their own Bugzilla instance to GitHub issues. While all of the links are still valid, they may not necessarily show the most
treewide: update LLVM Bugzilla links
LLVM moved their issue tracker from their own Bugzilla instance to GitHub issues. While all of the links are still valid, they may not necessarily show the most up to date information around the issues, as all updates will occur on GitHub, not Bugzilla.
Another complication is that the Bugzilla issue number is not always the same as the GitHub issue number. Thankfully, LLVM maintains this mapping through two shortlinks:
https://llvm.org/bz<num> -> https://bugs.llvm.org/show_bug.cgi?id=<num> https://llvm.org/pr<num> -> https://github.com/llvm/llvm-project/issues/<mapped_num>
Switch all "https://bugs.llvm.org/show_bug.cgi?id=<num>" links to the "https://llvm.org/pr<num>" shortlink so that the links show the most up to date 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.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Fangrui Song <maskray@google.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Mykola Lysenko <mykolal@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
d2e527f0 |
| 23-May-2023 |
Vlastimil Babka <vbabka@suse.cz> |
mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATOR
With SLOB removed, both remaining allocators support hardened usercopy, so remove the config and associated #ifdef.
Signed-off-by: Vlastimil Babka <
mm/slab: remove HAVE_HARDENED_USERCOPY_ALLOCATOR
With SLOB removed, both remaining allocators support hardened usercopy, so remove the config and associated #ifdef.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: David Rientjes <rientjes@google.com> Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
show more ...
|
#
ff61f079 |
| 14-Mar-2023 |
Jonathan Corbet <corbet@lwn.net> |
docs: move x86 documentation into Documentation/arch/
Move the x86 documentation under Documentation/arch/ as a way of cleaning up the top-level directory and making the structure of our docs more c
docs: move x86 documentation into Documentation/arch/
Move the x86 documentation under Documentation/arch/ as a way of cleaning up the top-level directory and making the structure of our docs more closely match the structure of the source directories it describes.
All in-kernel references to the old paths have been updated.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-arch@vger.kernel.org Cc: x86@kernel.org Cc: Borislav Petkov <bp@alien8.de> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/lkml/20230315211523.108836-1-corbet@lwn.net/ Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
#
f22f9aaf |
| 17-Mar-2023 |
Paul Moore <paul@paul-moore.com> |
selinux: remove the runtime disable functionality
After working with the larger SELinux-based distros for several years, we're finally at a place where we can disable the SELinux runtime disable fun
selinux: remove the runtime disable functionality
After working with the larger SELinux-based distros for several years, we're finally at a place where we can disable the SELinux runtime disable functionality. The existing kernel deprecation notice 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 the diffstat you'll see that the impact of this patch reaches across all the different LSMs, helping prevent tampering at the LSM hook level.
From a SELinux perspective, it is important to note that if you continue to disable SELinux via "/etc/selinux/config" it may appear that SELinux is disabled, but it is simply in an uninitialized state. If you load a policy with `load_policy -i`, you will see SELinux come alive just as if you had loaded the policy during early-boot.
It is also worth noting that the "/sys/fs/selinux/disable" file is always writable now, regardless of the Kconfig settings, but writing to the file has no effect on the system, other than to display an error on the console if a non-zero/true value is written.
Finally, in the several years where we have been working on deprecating this functionality, there has only been one instance of someone mentioning any user visible breakage. In this particular case it was an individual's kernel test system, and the workaround documented in the deprecation notice ("selinux=0" on the kernel command line) resolved the issue without problem.
Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
#
b9b8701b |
| 10-Mar-2023 |
Roberto Sassu <roberto.sassu@huawei.com> |
security: Remove integrity from the LSM list in Kconfig
Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer necessary. Since the recent change (set order to LSM_ORDER_LAST), the
security: Remove integrity from the LSM list in Kconfig
Remove 'integrity' from the list of LSMs in Kconfig, as it is no longer necessary. Since the recent change (set order to LSM_ORDER_LAST), the 'integrity' LSM is always enabled (if selected in the kernel configuration).
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
show more ...
|
#
f43b9876 |
| 27-Jun-2022 |
Peter Zijlstra <peterz@infradead.org> |
x86/retbleed: Add fine grained Kconfig knobs
Do fine-grained Kconfig for all the various retbleed parts.
NOTE: if your compiler doesn't support return thunks this will silently 'upgrade' your mitig
x86/retbleed: Add fine grained Kconfig knobs
Do fine-grained Kconfig for all the various retbleed parts.
NOTE: if your compiler doesn't support return thunks this will silently 'upgrade' your mitigation to IBPB, you might not like this.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de>
show more ...
|
#
1109a5d9 |
| 10-Jan-2022 |
Matthew Wilcox (Oracle) <willy@infradead.org> |
usercopy: Remove HARDENED_USERCOPY_PAGESPAN
There isn't enough information to make this a useful check any more; the useful parts of it were moved in earlier patches, so remove this set of checks no
usercopy: Remove HARDENED_USERCOPY_PAGESPAN
There isn't enough information to make this a useful check any more; the useful parts of it were moved in earlier patches, so remove this set of checks now.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220110231530.665970-5-willy@infradead.org
show more ...
|
#
ef3e787c |
| 24-Mar-2022 |
Kees Cook <keescook@chromium.org> |
usercopy: Disable CONFIG_HARDENED_USERCOPY_PAGESPAN
CONFIG_HARDENED_USERCOPY_PAGESPAN has been mostly broken for a while, and it has become hard to ignore with some recent scsi changes[1]. While the
usercopy: Disable CONFIG_HARDENED_USERCOPY_PAGESPAN
CONFIG_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 kernel release.
[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 <hch@lst.de> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
281d0c96 |
| 08-Feb-2022 |
Kees Cook <keescook@chromium.org> |
fortify: Add Clang support
Enable FORTIFY_SOURCE support for Clang:
Use the new __pass_object_size and __overloadable attributes so that Clang will have appropriate visibility into argument sizes s
fortify: Add Clang support
Enable FORTIFY_SOURCE support for Clang:
Use the new __pass_object_size and __overloadable attributes so that Clang will have appropriate visibility into argument sizes such that __builtin_object_size(p, 1) will behave correctly. Additional details available here: https://github.com/llvm/llvm-project/issues/53516 https://github.com/ClangBuiltLinux/linux/issues/1401
A bug with __builtin_constant_p() of globally defined variables was fixed in Clang 13 (and backported to 12.0.1), so FORTIFY support must depend 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 optimizations with Clang) cannot be done. Without the libcall optimizations, Clang cannot provide appropriate FORTIFY coverage, so it must be disabled for CONFIG_X86_32. Additional details here; https://github.com/llvm/llvm-project/issues/53645
Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: George Burgess IV <gbiv@google.com> Cc: llvm@lists.linux.dev Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20220208225350.1331628-9-keescook@chromium.org
show more ...
|
#
53944f17 |
| 05-Nov-2021 |
Stephen Kitt <steve@sk2.org> |
mm: remove HARDENED_USERCOPY_FALLBACK
This has served its purpose and is no longer used. All usercopy violations appear to have been handled by now, any remaining instances (or new bugs) will cause
mm: remove HARDENED_USERCOPY_FALLBACK
This has served its purpose and is no longer used. All usercopy violations 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: Allow strict enforcement of whitelists"); since usercopy_fallback is effectively 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/153 Link: https://lkml.kernel.org/r/20210921061149.1091163-1-steve@sk2.org Signed-off-by: Stephen Kitt <steve@sk2.org> Suggested-by: Kees Cook <keescook@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Joel Stanley <joel@jms.id.au> [defconfig change] Acked-by: David Rientjes <rientjes@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: James Morris <jmorris@namei.org> Cc: "Serge E . Hallyn" <serge@hallyn.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
a52f8a59 |
| 13-May-2021 |
Kees Cook <keescook@chromium.org> |
fortify: Explicitly disable Clang support
Clang has never correctly compiled the FORTIFY_SOURCE defenses due to a couple bugs:
Eliding inlines with matching __builtin_* names https://bugs.llvm.or
fortify: Explicitly disable Clang support
Clang has never correctly compiled the FORTIFY_SOURCE defenses due to a 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=41459
In the process of making improvements to the FORTIFY_SOURCE defenses, the first (silent) bug (coincidentally) becomes worked around, but exposes the latter which breaks the build. As such, Clang must not be used with CONFIG_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 <keescook@chromium.org> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com
show more ...
|
#
385975dc |
| 22-Apr-2021 |
Mickaël Salaün <mic@linux.microsoft.com> |
landlock: Set up the security framework and manage credentials
Process's credentials point to a Landlock domain, which is underneath implemented with a ruleset. In the following commits, this domai
landlock: Set up the security framework and manage credentials
Process's credentials point to a Landlock domain, which is underneath implemented with a ruleset. In the following commits, this domain is used to check and enforce the ptrace and filesystem security policies. A domain is inherited from a parent to its child the same way a thread inherits a seccomp policy.
Cc: James Morris <jmorris@namei.org> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> Reviewed-by: Jann Horn <jannh@google.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210422154123.13086-4-mic@digikod.net Signed-off-by: James Morris <jamorris@linux.microsoft.com>
show more ...
|
#
90945448 |
| 22-Apr-2021 |
Mickaël Salaün <mic@linux.microsoft.com> |
landlock: Add object management
A 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. Rules are grouped in rulesets
landlock: Add object management
A 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. Rules are 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 (especially unprivileged ones) to sandbox themselves, we cannot rely on a system-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 objects while this identification is useful (i.e. when a security policy makes use of this object). But this identification data should be freed once no policy is using it. This ephemeral tagging should not and may not be written in the filesystem. We then need to manage the lifetime of a rule according to the lifetime of its objects. To avoid a global lock, this implementation make use of RCU and counters to safely reference objects.
A following commit uses this generic object management for inodes.
Cc: James Morris <jmorris@namei.org> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> Reviewed-by: Jann Horn <jannh@google.com> Acked-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210422154123.13086-2-mic@digikod.net Signed-off-by: James Morris <jamorris@linux.microsoft.com>
show more ...
|
#
c9fecf50 |
| 05-Jul-2020 |
Alexander A. Klimov <grandmaster@al2klimov.de> |
Replace HTTP links with HTTPS ones: security
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm: For
Replace HTTP links with HTTPS ones: security
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
#
520b7aa0 |
| 29-Mar-2020 |
KP Singh <kpsingh@google.com> |
bpf: lsm: Initialize the BPF LSM hooks
* The hooks are initialized using the definitions in include/linux/lsm_hook_defs.h. * The LSM can be enabled / disabled with CONFIG_BPF_LSM.
Signed-off-by:
bpf: lsm: Initialize the BPF LSM hooks
* The hooks are initialized using the definitions in include/linux/lsm_hook_defs.h. * The LSM can be enabled / disabled with CONFIG_BPF_LSM.
Signed-off-by: KP Singh <kpsingh@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Florent Revest <revest@google.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: James Morris <jamorris@linux.microsoft.com> Link: https://lore.kernel.org/bpf/20200329004356.27286-6-kpsingh@chromium.org
show more ...
|
#
000d388e |
| 20-Aug-2019 |
Matthew Garrett <matthewgarrett@google.com> |
security: Add a static lockdown policy LSM
While existing LSMs can be extended to handle lockdown policy, distributions generally want to be able to apply a straightforward static policy. This patch
security: Add a static lockdown policy LSM
While existing LSMs can be extended to handle lockdown policy, distributions generally want to be able to apply a straightforward static policy. This patch adds a simple LSM that can be configured to reject either integrity or all lockdown queries, and can be configured at runtime (through securityfs), boot time (via a kernel parameter) or build time (via a kconfig option). Based on initial code by David Howells.
Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
show more ...
|
#
e8d776f2 |
| 20-Apr-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
docs: x86: move two x86-specific files to x86 arch dir
Those two docs belong to the x86 architecture:
Documentation/Intel-IOMMU.txt -> Documentation/x86/intel-iommu.rst Documentation/intel_tx
docs: x86: move two x86-specific files to x86 arch dir
Those two docs belong to the x86 architecture:
Documentation/Intel-IOMMU.txt -> Documentation/x86/intel-iommu.rst Documentation/intel_txt.txt -> Documentation/x86/intel_txt.rst
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
show more ...
|
#
cb1aaebe |
| 07-Jun-2019 |
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> |
docs: fix broken documentation links
Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+s
docs: fix broken documentation links
Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
show more ...
|
#
ec8f24b7 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
9f671e58 |
| 10-Apr-2019 |
Kees Cook <keescook@chromium.org> |
security: Create "kernel hardening" config area
Right now kernel hardening options are scattered around various Kconfig files. This can be a central place to collect these kinds of options going for
security: Create "kernel hardening" config area
Right now kernel hardening options are scattered around various Kconfig files. This can be a central place to collect these kinds of options going forward. This is initially populated with the memory initialization options from the gcc-plugins.
Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
#
2623c4fb |
| 29-Mar-2019 |
Kees Cook <keescook@chromium.org> |
LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from sec
LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from security/Kconfig and changed CONFIG_LSM to provide a fixed ordering as a default value. That commit expected that existing users (upgrading from Linux 5.0 and earlier) will edit CONFIG_LSM value in accordance with their CONFIG_DEFAULT_SECURITY_* choice in their old kernel configs. But since users might forget to edit CONFIG_LSM value, this patch revives the choice (only for providing the default value for CONFIG_LSM) in order to make sure that CONFIG_LSM reflects CONFIG_DEFAULT_SECURITY_* from their old kernel configs.
Note that since TOMOYO can be fully stacked against the other legacy major LSMs, when it is selected, it explicitly disables the other LSMs to avoid them also initializing since TOMOYO does not expect this currently.
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Fixes: 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") Co-developed-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
show more ...
|
#
b102c11e |
| 28-Feb-2019 |
Petr Vorel <pvorel@suse.cz> |
LSM: Update list of SECURITYFS users in Kconfig
Remove modules not using it (SELinux and SMACK aren't the only ones not using it).
Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: James Mo
LSM: Update list of SECURITYFS users in Kconfig
Remove modules not using it (SELinux and SMACK aren't the only ones not using it).
Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: James Morris <james.morris@microsoft.com>
show more ...
|
#
aeca4e2c |
| 16-Jan-2019 |
Micah Morton <mortonm@chromium.org> |
LSM: add SafeSetID module that gates setid calls
SafeSetID gates the setid family of syscalls to restrict UID/GID transitions from a given UID/GID to only those approved by a system-wide whitelist.
LSM: add SafeSetID module that gates setid calls
SafeSetID gates the setid family of syscalls to restrict UID/GID transitions from a given UID/GID to only those approved by a system-wide whitelist. These restrictions also prohibit the given UIDs/GIDs from obtaining auxiliary privileges associated with CAP_SET{U/G}ID, such as allowing a user to set up user namespace UID mappings. For now, only gating the set*uid family of syscalls is supported, with support for set*gid coming in a future patch set.
Signed-off-by: Micah Morton <mortonm@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
show more ...
|
#
d6aed64b |
| 14-Sep-2018 |
Kees Cook <keescook@chromium.org> |
Yama: Initialize as ordered LSM
This converts Yama from being a direct "minor" LSM into an ordered LSM.
Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufle
Yama: Initialize as ordered LSM
This converts Yama from being a direct "minor" LSM into an ordered LSM.
Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
show more ...
|