From: Roberto Sassu <roberto.sassu@huawei.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
Christoph Hellwig <hch@infradead.org>
Cc: "deven.desai@linux.microsoft.com"
<deven.desai@linux.microsoft.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>,
"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] device mapper: Add builtin function dm_get_status()
Date: Mon, 6 Dec 2021 10:57:41 +0000 [thread overview]
Message-ID: <e38392762299459890eee792a3a7cb09@huawei.com> (raw)
In-Reply-To: <28208b7f142f4295ac5c857af5cffe07@huawei.com>
> From: Roberto Sassu [mailto:roberto.sassu@huawei.com]
> Sent: Friday, December 3, 2021 11:20 AM
> > From: Christoph Hellwig [mailto:hch@infradead.org]
> > Sent: Friday, December 3, 2021 7:52 AM
> > On Thu, Dec 02, 2021 at 09:29:52AM +0000, Roberto Sassu wrote:
> > > The problem being solved is how to grant access to files
> > > which satisfy a property defined in the policy.
> >
> > If you have want to enforce access to files in the block layer using
> > a specific stacking block driver you don't just have one layering
> > violation but a bunch of them. Please go back to the drawing board.
>
> Ok. I write my thoughts here, so that it is easier to align.
>
> dm-verity provides block-level integrity, which means that
> the block layer itself is responsible to not pass data to the
> upper layer, the filesystem, if a block is found corrupted.
>
> The dm-verity root digest represents the immutable state
> of the block device. dm-verity is still responsible to enforce
> accesses to the block device according to the root digest
> passed at device setup time. Nothing changes, the block
> layer still detects data corruption against the passed
> reference value.
>
> The task of the security layer is to decide whether or not
> the root digest passed at device setup time is acceptable,
> e.g. it represents a device containing genuine files coming
> from a software vendor.
>
> The mandatory policy can be enforced at different layers,
> depending on whether the security controls are placed.
> A possibility would be to deny mounting block devices that
> don't satisfy the mandatory policy.
>
> However, if the mandatory policy wants only to restrict
> execution of approved files and allowing the rest, making
> the decision at the block layer is too coarse and restrictive.
> It would force the user to mount only approved block
> devices. The security layer must operate on files to enforce
> this policy.
>
> Now probably there is the part where there is no agreement.
>
> The integrity property of a block device applies also to the
> files on the filesystem mounted from that device. User space
> programs cannot access files in that filesystem coming from a
> device with a different dm-verity root digest, or files stored
> in a corrupted block device.
>
> If what I wrote is correct, that the integrity property is preserved
> across the layers, this would give enough flexibility to enforce
> policies at a higher layer, although that property is guaranteed
> by a lower layer.
Hi Christoph
did I address your concerns? If yes, I could send the new patch
set, including the patch that uses the new functionality.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
next prev parent reply other threads:[~2021-12-06 10:57 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
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 [this message]
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=e38392762299459890eee792a3a7cb09@huawei.com \
--to=roberto.sassu@huawei.com \
--cc=agk@redhat.com \
--cc=axboe@kernel.dk \
--cc=corbet@lwn.net \
--cc=deven.desai@linux.microsoft.com \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--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=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).