linux/security/loadpin, branch v6.3

LoadPin: Allow filesystem switch when not enforcing

2023-01-19T23:18:20Z

For LoadPin to be used at all in a classic distro environment, it needs to allow for switching filesystems (from the initramfs to the "real" root filesystem). To allow for this, if the "enforce" mode is not set at boot, reset the pinned filesystem tracking when the pinned filesystem gets unmounted instead of invalidating further loads. Once enforcement is set, it cannot be unset, and the pinning will stick. This means that distros can build with CONFIG_SECURITY_LOADPIN=y, but with CONFIG_SECURITY_LOADPIN_ENFORCE disabled, but after boot is running, the system can enable enforcement: $ sysctl -w kernel.loadpin.enforced=1 Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Serge Hallyn Link: https://lore.kernel.org/r/20221209195746.1366607-4-keescook@chromium.org

LoadPin: Move pin reporting cleanly out of locking

2023-01-19T23:18:20Z

Refactor the pin reporting to be more cleanly outside the locking. It was already, but moving it around helps clear the path for the root to switch when not enforcing. Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Serge Hallyn Link: https://lore.kernel.org/r/20221209195746.1366607-3-keescook@chromium.org

LoadPin: Refactor sysctl initialization

2023-01-19T23:18:20Z

In preparation for shifting root mount when not enforcing, split sysctl logic out into a separate helper, and unconditionally register the sysctl, but only make it writable when the device is writable. Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Serge Hallyn Link: https://lore.kernel.org/r/20221209195746.1366607-2-keescook@chromium.org

LoadPin: Refactor read-only check into a helper

2023-01-19T23:18:20Z

In preparation for allowing mounts to shift when not enforced, move read-only checking into a separate helper. Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Serge Hallyn Link: https://lore.kernel.org/r/20221209195746.1366607-1-keescook@chromium.org

LoadPin: Ignore the "contents" argument of the LSM hooks

2022-12-14T22:34:18Z

LoadPin only enforces the read-only origin of kernel file reads. Whether or not it was a partial read isn't important. Remove the overly conservative checks so that things like partial firmware reads will succeed (i.e. reading a firmware header). Fixes: 2039bda1fa8d ("LSM: Add "contents" flag to kernel_read_file hook") Cc: Paul Moore Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook Acked-by: Serge Hallyn Tested-by: Ping-Ke Shih Link: https://lore.kernel.org/r/20221209195453.never.494-kees@kernel.org

LoadPin: Require file with verity root digests to have a header

2022-09-07T23:37:27Z

LoadPin expects the file with trusted verity root digests to be an ASCII file with one digest (hex value) per line. A pinned root could contain files that meet these format requirements, even though the hex values don't represent trusted root digests. Add a new requirement to the file format which consists in the first line containing a fixed string. This prevents attackers from feeding files with an otherwise valid format to LoadPin. Suggested-by: Sarthak Kukreti Signed-off-by: Matthias Kaehlcke Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220906181725.1.I3f51d1bb0014e5a5951be4ad3c5ad7c7ca1dfc32@changeid

LoadPin: Fix Kconfig doc about format of file with verity digests

2022-09-07T23:37:27Z

The doc for CONFIG_SECURITY_LOADPIN_VERITY says that the file with verity digests must contain a comma separated list of digests. That was the case at some stage of the development, but was changed during the review process to one digest per line. Update the Kconfig doc accordingly. Reported-by: Jae Hoon Kim Signed-off-by: Matthias Kaehlcke Fixes: 3f805f8cc23b ("LoadPin: Enable loading from trusted dm-verity devices") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220829174557.1.I5d202d1344212a3800d9828f936df6511eb2d0d1@changeid

LoadPin: Return EFAULT on copy_from_user() failures

2022-08-16T19:17:18Z

The copy_from_user() function returns the number of bytes remaining to be copied on a failure. Such failures should return -EFAULT to high levels. Reported-by: kernel test robot Reported-by: Dan Carpenter Fixes: 3f805f8cc23b ("LoadPin: Enable loading from trusted dm-verity devices") Cc: Matthias Kaehlcke Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-security-module@vger.kernel.org Signed-off-by: Kees Cook

LoadPin: Enable loading from trusted dm-verity devices

2022-07-08T17:46:53Z

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 Acked-by: Mike Snitzer Link: https://lore.kernel.org/lkml/20220627083512.v7.2.I01c67af41d2f6525c6d023101671d7339a9bc8b5@changeid Signed-off-by: Kees Cook

loadpin: stop using bdevname

2022-05-16T23:02:21Z

Use the %pg format specifier to save on stack consuption and code size. Signed-off-by: Christoph Hellwig Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220512062014.1826835-1-hch@lst.de