From: Deven Bowers <deven.desai@linux.microsoft.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"agk@redhat.com" <agk@redhat.com>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"ebiggers@kernel.org" <ebiggers@kernel.org>,
"tytso@mit.edu" <tytso@mit.edu>,
"paul@paul-moore.com" <paul@paul-moore.com>,
"eparis@redhat.com" <eparis@redhat.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>
Cc: "jannh@google.com" <jannh@google.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"tusharsu@linux.microsoft.com" <tusharsu@linux.microsoft.com>
Subject: Re: [RFC PATCH v7 11/16] ipe: add support for dm-verity as a trust provider
Date: Tue, 30 Nov 2021 10:55:20 -0800 [thread overview]
Message-ID: <81d5e825-1ee2-8f6b-cd9d-07b0f8bd36d3@linux.microsoft.com> (raw)
In-Reply-To: <721462c3da064d359ca3c83845298ccf@huawei.com>
On 11/25/2021 1:37 AM, Roberto Sassu wrote:
>> From: deven.desai@linux.microsoft.com
>> [mailto:deven.desai@linux.microsoft.com]
>> Sent: Wednesday, October 13, 2021 9:07 PM
>> From: Deven Bowers <deven.desai@linux.microsoft.com>
..snip
>> diff --git a/security/ipe/modules/Makefile b/security/ipe/modules/Makefile
>> index e0045ec65434..84fadce85193 100644
>> --- a/security/ipe/modules/Makefile
>> +++ b/security/ipe/modules/Makefile
>> @@ -6,3 +6,5 @@
>> #
>>
>> obj-$(CONFIG_IPE_PROP_BOOT_VERIFIED) += boot_verified.o
>> +obj-$(CONFIG_IPE_PROP_DM_VERITY_SIGNATURE) += dmverity_signature.o
>> +obj-$(CONFIG_IPE_PROP_DM_VERITY_ROOTHASH) += dmverity_roothash.o
>> diff --git a/security/ipe/modules/dmverity_roothash.c
>> b/security/ipe/modules/dmverity_roothash.c
>> new file mode 100644
>> index 000000000000..0f82bec3b842
>> --- /dev/null
>> +++ b/security/ipe/modules/dmverity_roothash.c
>> @@ -0,0 +1,80 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) Microsoft Corporation. All rights reserved.
>> + */
>> +
>> +#include "ipe_module.h"
>> +
>> +#include <linux/fs.h>
>> +#include <linux/types.h>
>> +
>> +struct counted_array {
>> + size_t len;
>> + u8 *data;
>> +};
>> +
>> +static int dvrh_parse(const char *valstr, void **value)
>> +{
>> + int rv = 0;
>> + struct counted_array *arr;
>> +
>> + arr = kzalloc(sizeof(*arr), GFP_KERNEL);
>> + if (!arr) {
>> + rv = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + arr->len = (strlen(valstr) / 2);
>> +
>> + arr->data = kzalloc(arr->len, GFP_KERNEL);
>> + if (!arr->data) {
>> + rv = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + rv = hex2bin(arr->data, valstr, arr->len);
>> + if (rv != 0)
>> + goto err2;
>> +
>> + *value = arr;
>> + return rv;
>> +err2:
>> + kfree(arr->data);
>> +err:
>> + kfree(arr);
>> + return rv;
>> +}
>> +
>> +static bool dvrh_eval(const struct ipe_eval_ctx *ctx, const void *val)
>> +{
>> + const u8 *src;
>> + struct counted_array *expect = (struct counted_array *)val;
>> +
>> + if (!ctx->ipe_bdev)
>> + return false;
>> +
>> + if (ctx->ipe_bdev->hashlen != expect->len)
>> + return false;
>> +
>> + src = ctx->ipe_bdev->hash;
>> +
>> + return !memcmp(expect->data, src, expect->len);
> Hi Deven
>
> I was curious to see if determining the property at run-time
> could apply also to dm-verity. It seems it could be done
> (I omit some checks, I also keep the expected value in hex
> format):
>
> ---
> md = dm_get_md(file_inode(ctx->file)->i_sb->s_dev);
> table = dm_get_live_table(md, &srcu_idx);
> num_targets = dm_table_get_num_targets(table);
>
> for (i = 0; i < num_targets; i++) {
> struct dm_target *ti = dm_table_get_target(table, i);
>
> if (strcmp(ti->type->name, "verity"))
> continue;
>
> ti->type->status(ti, STATUSTYPE_IMA, 0, result, sizeof(result));
> }
>
> dm_put_live_table(md, srcu_idx);
> dm_put(md);
>
> root_digest_ptr = strstr(result, "root_digest=");
> return !strncmp(expect->data, root_digest_ptr + 12, expect->len);
> ---
>
> Only dm_table_get_target() is not exported yet, but I guess it could
> be. dm_table_get_num_targets() is exported.
I had tried something similar in a very early draft of IPE. The issue
that comes with this is that when you compile device-mapper as a module
(CONFIG_BLK_DEV_DM=m) you start to get linking errors with this
approach.
Obviously, we can fix this in the IPE's module Kconfig by setting the
dependency to be =y, but it's something to highlight. My general
preference is to support the =m configuration by using these blobs.
The runtime approach does work with fs-verity, because fs-verity is a
file-system level feature that cannot be compiled as a module.
> With this code, you would not have to manage security blobs
> outside IPE. Maybe you could add a blob for the super block, so
> that you verify the dm-verity property just once per filesystem.
>
> Roberto
>
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Zhong Ronghua
>
>> +}
>> +
>> +static int dvrh_free(void **val)
>> +{
>> + struct counted_array *expect = (struct counted_array *)val;
>> +
>> + kfree(expect->data);
>> + kfree(expect);
>> +
>> + return 0;
>> +}
>> +
>> +IPE_MODULE(dvrh) = {
>> + .name = "dmverity_roothash",
>> + .version = 1,
>> + .parse = dvrh_parse,
>> + .free = dvrh_free,
>> + .eval = dvrh_eval,
>> +};
>> diff --git a/security/ipe/modules/dmverity_signature.c
>> b/security/ipe/modules/dmverity_signature.c
>> new file mode 100644
>> index 000000000000..08746fcbcb3e
>> --- /dev/null
>> +++ b/security/ipe/modules/dmverity_signature.c
>> @@ -0,0 +1,25 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) Microsoft Corporation. All rights reserved.
>> + */
>> +
>> +#include "ipe_module.h"
>> +
>> +#include <linux/fs.h>
>> +#include <linux/types.h>
>> +
>> +static bool dvv_eval(const struct ipe_eval_ctx *ctx, const void *val)
>> +{
>> + bool expect = (bool)val;
>> + bool eval = ctx->ipe_bdev && (!!ctx->ipe_bdev->sigdata);
>> +
>> + return expect == eval;
>> +}
>> +
>> +IPE_MODULE(dvv) = {
>> + .name = "dmverity_signature",
>> + .version = 1,
>> + .parse = ipe_bool_parse,
>> + .free = NULL,
>> + .eval = dvv_eval,
>> +};
>> --
>> 2.33.0
next prev parent reply other threads:[~2021-11-30 18:55 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 19:06 [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE) deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 01/16] security: add ipe lsm & initial context creation deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 02/16] ipe: add policy parser deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 03/16] ipe: add evaluation loop deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 04/16] ipe: add userspace interface deven.desai
2021-11-03 9:42 ` Roberto Sassu
2021-11-04 16:50 ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 05/16] ipe: add LSM hooks on execution and kernel read deven.desai
2021-10-13 20:04 ` Casey Schaufler
2021-10-15 19:25 ` Deven Bowers
2021-10-25 12:22 ` Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-27 8:56 ` Roberto Sassu
2021-10-13 19:06 ` [RFC PATCH v7 06/16] uapi|audit: add trust audit message definitions deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 07/16] ipe: add auditing support deven.desai
2021-10-13 20:02 ` Steve Grubb
2021-10-15 19:25 ` Deven Bowers
2021-11-02 19:44 ` Steve Grubb
2021-11-04 16:59 ` Deven Bowers
2021-10-13 22:54 ` Randy Dunlap
2021-10-15 19:25 ` Deven Bowers
2021-10-15 19:50 ` Randy Dunlap
2021-10-26 19:03 ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 08/16] ipe: add permissive toggle deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 09/16] ipe: introduce 'boot_verified' as a trust provider deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 10/16] fs|dm-verity: add block_dev LSM blob and submit dm-verity data deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 11/16] ipe: add support for dm-verity as a trust provider deven.desai
2021-11-25 9:37 ` Roberto Sassu
2021-11-30 18:55 ` Deven Bowers [this message]
2021-12-01 16:37 ` [RFC][PATCH] device mapper: Add builtin function dm_get_status() Roberto Sassu
2021-12-01 16:43 ` Roberto Sassu
2021-12-02 7:20 ` Christoph Hellwig
2021-12-02 7:59 ` Roberto Sassu
2021-12-02 8:44 ` Christoph Hellwig
2021-12-02 9:29 ` Roberto Sassu
2021-12-03 6:52 ` Christoph Hellwig
2021-12-03 10:20 ` Roberto Sassu
2021-12-06 10:57 ` Roberto Sassu
2021-10-13 19:06 ` [RFC PATCH v7 12/16] fsverity|security: add security hooks to fsverity digest and signature deven.desai
2021-10-13 19:24 ` Eric Biggers
2021-10-15 19:25 ` Deven Bowers
2021-10-15 20:11 ` Eric Biggers
2021-10-20 15:08 ` Roberto Sassu
2021-10-22 16:31 ` Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-27 8:41 ` Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-27 9:34 ` Roberto Sassu
2021-10-28 3:48 ` Eric Biggers
2021-10-28 18:11 ` Deven Bowers
2021-11-03 12:28 ` Roberto Sassu
2021-11-04 17:12 ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 13/16] ipe: enable support for fs-verity as a trust provider deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 14/16] scripts: add boot policy generation program deven.desai
2021-11-03 16:43 ` Roberto Sassu
2021-11-03 16:53 ` Roberto Sassu
2021-11-04 16:52 ` Deven Bowers
2021-10-13 19:06 ` [RFC PATCH v7 15/16] ipe: kunit tests deven.desai
2021-10-13 19:06 ` [RFC PATCH v7 16/16] documentation: add ipe documentation deven.desai
2021-10-25 11:30 ` [RFC PATCH v7 00/16] Integrity Policy Enforcement (IPE) Roberto Sassu
2021-10-26 19:03 ` Deven Bowers
2021-10-27 8:26 ` Roberto Sassu
2021-10-28 20:36 ` Deven Bowers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81d5e825-1ee2-8f6b-cd9d-07b0f8bd36d3@linux.microsoft.com \
--to=deven.desai@linux.microsoft.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=eparis@redhat.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=linux-audit@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=snitzer@redhat.com \
--cc=tusharsu@linux.microsoft.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).