linux.git/security/Kconfig, branch v5.2-rc2 Linux kernel source tree treewide: Add SPDX license identifier - Makefile/Kconfig 2019-05-21T08:50:46+00:00 Thomas Gleixner tglx@linutronix.de 2019-05-19T12:07:45+00:00 ec8f24b7faaf3d4799a7c3f4c1b87f6b02778ad1 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> 
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>
Merge tag 'meminit-v5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 2019-05-07T19:44:49+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-05-07T19:44:49+00:00 2d60d96b6f00de90ec2bc60eb4cdcc46e1e1f161 Pull compiler-based variable initialization updates from Kees Cook: "This is effectively part of my gcc-plugins tree, but as this adds some Clang support, it felt weird to still call it "gcc-plugins". :) This consolidates Kconfig for the existing stack variable initialization (via structleak and stackleak gcc plugins) and adds Alexander Potapenko's support for Clang's new similar functionality. Summary: - Consolidate memory initialization Kconfigs (Kees) - Implement support for Clang's stack variable auto-init (Alexander)" * tag 'meminit-v5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: security: Implement Clang's stack initialization security: Move stackleak config to Kconfig.hardening security: Create "kernel hardening" config area 
Pull compiler-based variable initialization updates from Kees Cook:
 "This is effectively part of my gcc-plugins tree, but as this adds some
  Clang support, it felt weird to still call it "gcc-plugins". :)

  This consolidates Kconfig for the existing stack variable
  initialization (via structleak and stackleak gcc plugins) and adds
  Alexander Potapenko's support for Clang's new similar functionality.

  Summary:

   - Consolidate memory initialization Kconfigs (Kees)

   - Implement support for Clang's stack variable auto-init (Alexander)"

* tag 'meminit-v5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  security: Implement Clang's stack initialization
  security: Move stackleak config to Kconfig.hardening
  security: Create "kernel hardening" config area
security: Create "kernel hardening" config area 2019-04-24T20:45:49+00:00 Kees Cook keescook@chromium.org 2019-04-10T15:23:44+00:00 9f671e58159adea641f76c56d1f0bbdcb3c524ff 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> 
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>
LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig" 2019-03-29T21:08:49+00:00 Kees Cook keescook@chromium.org 2019-03-29T19:36:04+00:00 2623c4fbe2ad1341ff2d1e12410d0afdae2490ca 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> 
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>
LSM: Update list of SECURITYFS users in Kconfig 2019-03-01T17:52:54+00:00 Petr Vorel pvorel@suse.cz 2019-02-28T23:54:48+00:00 b102c11e1a10e1328c9610665e45dd07bf4a3696 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> 
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>
LSM: add SafeSetID module that gates setid calls 2019-01-25T19:22:45+00:00 Micah Morton mortonm@chromium.org 2019-01-16T15:46:06+00:00 aeca4e2ca65c1aeacfbe520684e6421719d99417 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> 
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>
Yama: Initialize as ordered LSM 2019-01-08T21:18:43+00:00 Kees Cook keescook@chromium.org 2018-09-14T22:37:20+00:00 d6aed64b74b73b64278c059eacd59d87167aa968 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> 
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>
LoadPin: Initialize as ordered LSM 2019-01-08T21:18:43+00:00 Kees Cook keescook@chromium.org 2018-09-14T22:26:37+00:00 70b62c25665f636c9f6c700b26af7df296b0887e This converts LoadPin 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> 
This converts LoadPin 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>
LSM: Introduce "lsm=" for boottime LSM selection 2019-01-08T21:18:42+00:00 Kees Cook keescook@chromium.org 2018-09-20T00:30:09+00:00 79f7865d844c7703e3dc0e2f5b9ed2f3a4f412e5 Provide a way to explicitly choose LSM initialization order via the new "lsm=" comma-separated list of LSMs. Signed-off-by: Kees Cook <keescook@chromium.org> 
Provide a way to explicitly choose LSM initialization order via the new
"lsm=" comma-separated list of LSMs.

Signed-off-by: Kees Cook <keescook@chromium.org>
LSM: Introduce CONFIG_LSM 2019-01-08T21:18:42+00:00 Kees Cook keescook@chromium.org 2018-10-09T21:27:46+00:00 13e735c0e953246bd531d342bb86acb5b1bf664a This provides a way to declare LSM initialization order via the new CONFIG_LSM. Currently only non-major LSMs are recognized. This will be expanded in future patches. Signed-off-by: Kees Cook <keescook@chromium.org> 
This provides a way to declare LSM initialization order via the new
CONFIG_LSM. Currently only non-major LSMs are recognized. This will
be expanded in future patches.

Signed-off-by: Kees Cook <keescook@chromium.org>