| Message ID | 20220426143059.v2.2.I01c67af41d2f6525c6d023101671d7339a9bc8b5@changeid (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Mike Snitzer |
| Headers | show |
| Series | LoadPin: Enable loading from trusted dm-verity devices | expand |
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: sh-buildonly-randconfig-r004-20220427 (https://download.01.org/0day-ci/archive/20220427/202204272332.Ro5WIkwF-lkp@intel.com/config)
compiler: sh4-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=sh SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
sh4-linux-ld: security/loadpin/loadpin.o: in function `loadpin_read_file':
loadpin.c:(.text+0x2ac): undefined reference to `dm_get_md'
>> sh4-linux-ld: loadpin.c:(.text+0x2b0): undefined reference to `dm_put'
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/202204280323.OzDYYX55-lkp@intel.com/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 <lkp@intel.com>
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
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).
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). -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
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; }
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 <mka@chromium.org> --- 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(-)