LinuxLists.cc - [PATCH v2 2/3] LoadPin: Enable loading from trusted dm-verity devices

2022-04-27 10:37:31

Subject: [PATCH v2 2/3] 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. Userspace can use the new systl file
'loadpin/trusted_verity_root_digests_path' to provide
LoadPin with the path of a file with a list of root digests
from dm-verity devices that LoadPin should consider as
trusted. This file must be located on the pinned root.

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.

The path of the file with the trusted root digests can
only be written once, which is typically done at boot time.

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 <[email protected]>
---
I'm still doubting what would be the best way to configure
the list of trusted digests. The approach in v2 of writing
a path through sysctl is flexible, but it also feels a bit
odd. I did some experiments with passing a file descriptor
through sysctl, but it's also odd and has its own issues.
Passing the list through a kernel parameter seems hacky.
A Kconfig string would work, but can be have issues when
the same config is used for different platforms, where
some may have trusted digests and others not.

Changes in v2:
- userspace now passes the path of the file with the verity digests
via systcl, instead of the digests themselves
- renamed sysctl file to 'trusted_verity_root_digests_path'
- have CONFIG_SECURITY_LOADPIN_VERITY depend on CONFIG_SYSCTL
- updated Kconfig doc
- updated commit message

security/loadpin/Kconfig | 16 +++
security/loadpin/loadpin.c | 200 ++++++++++++++++++++++++++++++++++++-
2 files changed, 215 insertions(+), 1 deletion(-)

diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
index 91be65dec2ab..20681dc4b8a5 100644
--- a/security/loadpin/Kconfig
+++ b/security/loadpin/Kconfig
@@ -18,3 +18,19 @@ config SECURITY_LOADPIN_ENFORCE
If selected, LoadPin will enforce pinning at boot. If not
selected, it can be enabled at boot with the kernel parameter
"loadpin.enforce=1".
+
+config SECURITY_LOADPIN_VERITY
+ bool "Allow reading files from certain other filesystems that use dm-verity"
+ depends on DM_VERITY=y && SYSCTL
+ 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.
+
+ Userspace can populate the list of trusted digests by writing
+ the path of a file with the digests to the syctl file
+ 'trusted_verity_root_digests_path'. The file must be located
+ on the pinned root and contain a comma separated list of
+ digests.
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index b12f7d986b1e..db10b7ff6efd 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -18,6 +18,8 @@
#include <linux/path.h>
#include <linux/sched.h> /* current */
#include <linux/string_helpers.h>
+#include <linux/device-mapper.h>
+#include <linux/dm-verity-loadpin.h>

static void report_load(const char *origin, struct file *file, char *operation)
{
@@ -43,6 +45,10 @@ static char *exclude_read_files[READING_MAX_ID];
static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
static struct super_block *pinned_root;
static DEFINE_SPINLOCK(pinned_root_spinlock);
+#ifdef CONFIG_SECURITY_LOADPIN_VERITY
+static LIST_HEAD(trusted_verity_root_digests);
+static const char *verity_digests_path;
+#endif

#ifdef CONFIG_SYSCTL

@@ -65,6 +71,176 @@ static struct ctl_table loadpin_sysctl_table[] = {
{ }
};

+#ifdef CONFIG_SECURITY_LOADPIN_VERITY
+
+static int loadpin_read_file(struct file *file, enum kernel_read_file_id id,
+ bool contents);
+
+static int read_trusted_verity_root_digests(struct file *file)
+{
+ void *data;
+ char *p, *d;
+ int err, rc;
+
+ data = kzalloc(SZ_4K, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ rc = kernel_read_file(file, 0, &data, SZ_4K - 1, NULL, READING_POLICY);
+ if (rc < 0)
+ return rc;
+
+ ((char *)data)[rc] = '\0';
+
+ p = strim(data);
+ while ((d = strsep(&p, ",")) != NULL) {
+ int len = strlen(d);
+ struct trusted_root_digest *trd;
+
+ if (len % 2) {
+ err = -EPROTO;
+ goto free_mem;
+ }
+
+ len /= 2;
+
+ trd = kzalloc(sizeof(*trd), GFP_KERNEL);
+ if (!trd) {
+ err = -ENOMEM;
+ goto free_mem;
+ }
+
+ trd->data = kzalloc(len, GFP_KERNEL);
+ if (!trd->data) {
+ kfree(trd);
+ err = -ENOMEM;
+ goto free_mem;
+ }
+
+ if (hex2bin(trd->data, d, len)) {
+ kfree(trd);
+ err = -EPROTO;
+ goto free_mem;
+ }
+
+ list_add_tail(&trd->node, &trusted_verity_root_digests);
+
+ trd->len = len;
+ }
+
+ kfree(data);
+
+ return 0;
+
+free_mem:
+ kfree(data);
+
+ {
+ struct trusted_root_digest *trd, *tmp;
+
+ list_for_each_entry_safe(trd, tmp, &trusted_verity_root_digests, node) {
+ kfree(trd->data);
+ list_del(&trd->node);
+ kfree(trd);
+ }
+ }
+
+ return err;
+}
+
+static int proc_verity_digests(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct ctl_table tbl = *table;
+
+ if (write) {
+ int rc;
+ char *digests_path;
+ struct file *file;
+
+ if (*ppos)
+ return -EINVAL;
+
+ if (verity_digests_path != NULL)
+ return -EPERM;
+
+ digests_path = kzalloc(tbl.maxlen, GFP_KERNEL);
+ if (!digests_path)
+ return -ENOMEM;
+
+ tbl.data = digests_path;
+
+ rc = proc_dostring(&tbl, write, buffer, lenp, ppos);
+ if (rc) {
+ kfree(digests_path);
+ return rc;
+ }
+
+ /* only absolute paths are allowed */
+ if (digests_path[0] != '/') {
+ kfree(digests_path);
+ return -EINVAL;
+ }
+
+ file = filp_open(digests_path, O_RDONLY, 0);
+ if (IS_ERR(file)) {
+ int err = PTR_ERR(file);
+
+ if (err == -ENOENT) {
+ kfree(digests_path);
+ return -EINVAL;
+ }
+
+ return err;
+ }
+
+ /* verify the root digests stem from a trusted file system */
+ if (loadpin_read_file(file, READING_POLICY, true)) {
+ fput(file);
+ kfree(digests_path);
+ return -EPERM;
+ }
+
+ rc = read_trusted_verity_root_digests(file);
+ fput(file);
+ if (rc) {
+ kfree(digests_path);
+ return rc;
+ }
+
+ verity_digests_path = digests_path;
+ } else {
+ if (verity_digests_path) {
+ tbl.data = kzalloc(strlen(verity_digests_path) + 1, GFP_KERNEL);
+ strcpy(tbl.data, verity_digests_path);
+ } else {
+ tbl.data = kzalloc(1, GFP_KERNEL);
+ }
+
+ proc_dostring(&tbl, write, buffer, lenp, ppos);
+ kfree(tbl.data);
+ }
+
+ return 0;
+}
+
+static struct ctl_table loadpin_sysctl_table_verity_digests[] = {
+ {
+ .procname = "trusted_verity_root_digests_path",
+ .maxlen = SZ_256,
+ .mode = 0644,
+ .proc_handler = proc_verity_digests,
+ },
+
+ { }
+};
+
+#else
+
+static struct ctl_table loadpin_sysctl_table_verity_digests[] = {};
+
+#endif /* CONFIG_SECURITY_LOADPIN_VERITY */
+
/*
* This must be called after early kernel init, since then the rootdev
* is available.
@@ -118,6 +294,20 @@ static void loadpin_sb_free_security(struct super_block *mnt_sb)
}
}

+static bool loadpin_is_fs_trusted(struct super_block *sb)
+{
+ struct mapped_device *md = dm_get_md(sb->s_bdev->bd_dev);
+ bool trusted;
+
+ if (!md)
+ return false;
+
+ trusted = dm_verity_loadpin_is_md_trusted(md);
+ dm_put(md);
+
+ return trusted;
+}
+
static int loadpin_read_file(struct file *file, enum kernel_read_file_id id,
bool contents)
{
@@ -174,7 +364,8 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id,
spin_unlock(&pinned_root_spinlock);
}

- if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
+ if (IS_ERR_OR_NULL(pinned_root) ||
+ ((load_root != pinned_root) && !loadpin_is_fs_trusted(load_root))) {
if (unlikely(!enforce)) {
report_load(origin, file, "pinning-ignored");
return 0;
@@ -240,6 +431,13 @@ static int __init loadpin_init(void)
enforce ? "" : "not ");
parse_exclude();
security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
+
+ if (IS_ENABLED(CONFIG_SECURITY_LOADPIN_VERITY)) {
+ if (!register_sysctl_paths(loadpin_sysctl_path,
+ loadpin_sysctl_table_verity_digests))
+ pr_notice("sysctl registration failed!\n");
+ }
+
return 0;
}

--
2.36.0.rc2.479.g8af0fa9b8e-goog

2022-04-27 16:47:31

by kernel test robot

[permalink] [raw]

Subject: Re: [PATCH v2 2/3] LoadPin: Enable loading from trusted dm-verity devices

2022-04-28 08:00:46

by kernel test robot

[permalink] [raw]

Subject: Re: [PATCH v2 2/3] LoadPin: Enable loading from trusted dm-verity devices

Hi Matthias,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on device-mapper-dm/for-next]
[also build test ERROR on song-md/md-next kees/for-next/pstore v5.18-rc4 next-20220427]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url: https://github.com/intel-lab-lkp/linux/commits/Matthias-Kaehlcke/LoadPin-Enable-loading-from-trusted-dm-verity-devices/20220427-053314
base: https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git for-next
config: alpha-randconfig-r024-20220425 (https://download.01.org/0day-ci/archive/20220428/[email protected]/config)
compiler: alpha-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/f3a54909bcd78b9f7f006d7e78acd03987031fae
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Matthias-Kaehlcke/LoadPin-Enable-loading-from-trusted-dm-verity-devices/20220427-053314
git checkout f3a54909bcd78b9f7f006d7e78acd03987031fae
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=alpha SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>

All errors (new ones prefixed by >>):

security/loadpin/loadpin.c: In function 'loadpin_init':
security/loadpin/loadpin.c:436:44: error: 'loadpin_sysctl_path' undeclared (first use in this function)
436 | if (!register_sysctl_paths(loadpin_sysctl_path,
| ^~~~~~~~~~~~~~~~~~~
security/loadpin/loadpin.c:436:44: note: each undeclared identifier is reported only once for each function it appears in
>> security/loadpin/loadpin.c:437:44: error: 'loadpin_sysctl_table_verity_digests' undeclared (first use in this function)
437 | loadpin_sysctl_table_verity_digests))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

vim +/loadpin_sysctl_table_verity_digests +437 security/loadpin/loadpin.c

427
428 static int __init loadpin_init(void)
429 {
430 pr_info("ready to pin (currently %senforcing)\n",
431 enforce ? "" : "not ");
432 parse_exclude();
433 security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
434
435 if (IS_ENABLED(CONFIG_SECURITY_LOADPIN_VERITY)) {
436 if (!register_sysctl_paths(loadpin_sysctl_path,
> 437 loadpin_sysctl_table_verity_digests))
438 pr_notice("sysctl registration failed!\n");
439 }
440
441 return 0;
442 }
443

--
0-DAY CI Kernel Test Service
https://01.org/lkp

2022-05-01 11:28:38

by Kees Cook

[permalink] [raw]

Subject: Re: [PATCH v2 2/3] LoadPin: Enable loading from trusted dm-verity devices

On Tue, Apr 26, 2022 at 02:31:09PM -0700, Matthias Kaehlcke wrote:
> I'm still doubting what would be the best way to configure
> the list of trusted digests. The approach in v2 of writing
> a path through sysctl is flexible, but it also feels a bit
> odd. I did some experiments with passing a file descriptor
> through sysctl, but it's also odd and has its own issues.
> Passing the list through a kernel parameter seems hacky.
> A Kconfig string would work, but can be have issues when
> the same config is used for different platforms, where
> some may have trusted digests and others not.

I prefer the idea of passing an fd, since that can just use LoadPin
itself to verify the origin of the fd.

I also agree, though, that it's weird as a sysctl. Possible thoughts:

- make it a new ioctl on /dev/mapper/control (seems reasonable given
that it's specifically about dm devices).
- have LoadPin grow a securityfs node, maybe something like
/sys/kernel/security/loadpin/dm-verify and do the ioctl there (seems
reasonable given that it's specifically about LoadPin, but is perhaps
more overhead to built the securityfs).

--
Kees Cook

2022-05-03 01:25:00

by Matthias Kaehlcke

[permalink] [raw]

Subject: Re: [PATCH v2 2/3] LoadPin: Enable loading from trusted dm-verity devices

On Sat, Apr 30, 2022 at 11:21:54PM -0700, Kees Cook wrote:
> On Tue, Apr 26, 2022 at 02:31:09PM -0700, Matthias Kaehlcke wrote:
> > I'm still doubting what would be the best way to configure
> > the list of trusted digests. The approach in v2 of writing
> > a path through sysctl is flexible, but it also feels a bit
> > odd. I did some experiments with passing a file descriptor
> > through sysctl, but it's also odd and has its own issues.
> > Passing the list through a kernel parameter seems hacky.
> > A Kconfig string would work, but can be have issues when
> > the same config is used for different platforms, where
> > some may have trusted digests and others not.
>
> I prefer the idea of passing an fd, since that can just use LoadPin
> itself to verify the origin of the fd.
>
> I also agree, though, that it's weird as a sysctl. Possible thoughts:
>
> - make it a new ioctl on /dev/mapper/control (seems reasonable given
> that it's specifically about dm devices).
> - have LoadPin grow a securityfs node, maybe something like
> /sys/kernel/security/loadpin/dm-verify and do the ioctl there (seems
> reasonable given that it's specifically about LoadPin, but is perhaps
> more overhead to built the securityfs).

Thanks for your feedback!

Agreed that an ioctl is preferable over a sysctl interface. I wasn't aware
of securityfs and prefer it over a /dev/mapper/control ioctl. Ultimately
the list of digests is meaningful to LoadPin, not (directly) to the device
mapper / verity. I'm not sure how well this feature of integrating LoadPin
with verity will be by the verity maintainers in the first place, it's
probably best to limit the LoadPin specific stuff in verity to a minimum.
I experimented a bit with the securityfs option, building it doesn't seem
too much of an overhead. If loadpin.c ends up too cluttered with the
verity and securityfs stuff I could try to outsource some of it to (a)
dedicated file(s).