leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5ca14835dc
linux/security/loadpin/Kconfig

37 lines
1.5 KiB
Plaintext
Raw Normal View History

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>
2019-05-19 12:07:45 +00:00
# SPDX-License-Identifier: GPL-2.0-only
LSM: LoadPin for kernel file loading restrictions This LSM enforces that kernel-loaded files (modules, firmware, etc) must all come from the same filesystem, with the expectation that such a filesystem is backed by a read-only device such as dm-verity or CDROM. This allows systems that have a verified and/or unchangeable filesystem to enforce module and firmware loading restrictions without needing to sign the files individually. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-04-20 22:46:28 +00:00
config SECURITY_LOADPIN
bool "Pin load of kernel files (modules, fw, etc) to one filesystem"
depends on SECURITY && BLOCK
help
Any files read through the kernel file reading interface
LSM: LoadPin: provide enablement CONFIG Instead of being enabled by default when SECURITY_LOADPIN is selected, provide an additional (default off) config to determine the boot time behavior. As before, the "loadpin.enabled=0/1" kernel parameter remains available. Suggested-by: James Morris <jmorris@namei.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-05-17 08:45:52 +00:00
(kernel modules, firmware, kexec images, security policy)
can be pinned to the first filesystem used for loading. When
enabled, any files that come from other filesystems will be
rejected. This is best used on systems without an initrd that
have a root filesystem backed by a read-only device such as
dm-verity or a CDROM.
LoadPin: Rename boot param "enabled" to "enforce" LoadPin's "enabled" setting is really about enforcement, not whether or not the LSM is using LSM hooks. Instead, split this out so that LSM enabling can be logically distinct from whether enforcement is happening (for example, the pinning happens when the LSM is enabled, but the pin is only checked when "enforce" is set). This allows LoadPin to continue to operate sanely in test environments once LSM enable/disable is centrally handled (i.e. we want LoadPin to be enabled separately from its enforcement). Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: John Johansen <john.johansen@canonical.com>
2018-09-24 21:43:59 +00:00
config SECURITY_LOADPIN_ENFORCE
LSM: LoadPin: provide enablement CONFIG Instead of being enabled by default when SECURITY_LOADPIN is selected, provide an additional (default off) config to determine the boot time behavior. As before, the "loadpin.enabled=0/1" kernel parameter remains available. Suggested-by: James Morris <jmorris@namei.org> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-05-17 08:45:52 +00:00
bool "Enforce LoadPin at boot"
depends on SECURITY_LOADPIN
help
If selected, LoadPin will enforce pinning at boot. If not
selected, it can be enabled at boot with the kernel parameter
LoadPin: Rename boot param "enabled" to "enforce" LoadPin's "enabled" setting is really about enforcement, not whether or not the LSM is using LSM hooks. Instead, split this out so that LSM enabling can be logically distinct from whether enforcement is happening (for example, the pinning happens when the LSM is enabled, but the pin is only checked when "enforce" is set). This allows LoadPin to continue to operate sanely in test environments once LSM enable/disable is centrally handled (i.e. we want LoadPin to be enabled separately from its enforcement). Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: John Johansen <john.johansen@canonical.com>
2018-09-24 21:43:59 +00:00
"loadpin.enforce=1".
LoadPin: Enable loading from trusted dm-verity devices Extend LoadPin to allow loading of kernel files from trusted dm-verity [1] devices. This change adds the concept of trusted verity devices to LoadPin. LoadPin maintains a list of root digests of verity devices it considers trusted. Userspace can populate this list through an ioctl on the new LoadPin securityfs entry 'dm-verity'. The ioctl receives a file descriptor of a file with verity digests as parameter. Verity reads the digests from this file after confirming that the file is located on the pinned root. The digest file must contain one digest per line. The list of trusted digests can only be set up once, which is typically done at boot time. When a kernel file is read LoadPin first checks (as usual) whether the file is located on the pinned root, if so the file can be loaded. Otherwise, if the verity extension is enabled, LoadPin determines whether the file is located on a verity backed device and whether the root digest of that device is in the list of trusted digests. The file can be loaded if the verity device has a trusted root digest. Background: As of now LoadPin restricts loading of kernel files to a single pinned filesystem, typically the rootfs. This works for many systems, however it can result in a bloated rootfs (and OTA updates) on platforms where multiple boards with different hardware configurations use the same rootfs image. Especially when 'optional' files are large it may be preferable to download/install them only when they are actually needed by a given board. Chrome OS uses Downloadable Content (DLC) [2] to deploy certain 'packages' at runtime. As an example a DLC package could contain firmware for a peripheral that is not present on all boards. DLCs use dm-verity to verify the integrity of the DLC content. [1] https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html [2] https://chromium.googlesource.com/chromiumos/platform2/+/HEAD/dlcservice/docs/developer.md Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Mike Snitzer <snitzer@kernel.org> Link: https://lore.kernel.org/lkml/20220627083512.v7.2.I01c67af41d2f6525c6d023101671d7339a9bc8b5@changeid Signed-off-by: Kees Cook <keescook@chromium.org>
2022-06-27 15:35:25 +00:00
config SECURITY_LOADPIN_VERITY
bool "Allow reading files from certain other filesystems that use dm-verity"
depends on SECURITY_LOADPIN && DM_VERITY=y && SECURITYFS
help
If selected LoadPin can allow reading files from filesystems
that use dm-verity. LoadPin maintains a list of verity root
digests it considers trusted. A verity backed filesystem is
considered trusted if its root digest is found in the list
of trusted digests.
The list of trusted verity can be populated through an ioctl
on the LoadPin securityfs entry 'dm-verity'. The ioctl
expects a file descriptor of a file with verity digests as
parameter. The file must be located on the pinned root and
contain a comma separated list of digests.
Reference in New Issue Copy Permalink