[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28208b7f142f4295ac5c857af5cffe07@huawei.com>
Date: Fri, 3 Dec 2021 10:20:27 +0000
From: Roberto Sassu <roberto.sassu@...wei.com>
To: Christoph Hellwig <hch@...radead.org>
CC: "deven.desai@...ux.microsoft.com" <deven.desai@...ux.microsoft.com>,
"corbet@....net" <corbet@....net>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"agk@...hat.com" <agk@...hat.com>,
"snitzer@...hat.com" <snitzer@...hat.com>,
"ebiggers@...nel.org" <ebiggers@...nel.org>,
"tytso@....edu" <tytso@....edu>,
"paul@...l-moore.com" <paul@...l-moore.com>,
"eparis@...hat.com" <eparis@...hat.com>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"serge@...lyn.com" <serge@...lyn.com>,
"jannh@...gle.com" <jannh@...gle.com>,
"dm-devel@...hat.com" <dm-devel@...hat.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-fscrypt@...r.kernel.org" <linux-fscrypt@...r.kernel.org>,
"linux-audit@...hat.com" <linux-audit@...hat.com>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"tusharsu@...ux.microsoft.com" <tusharsu@...ux.microsoft.com>
Subject: RE: [RFC][PATCH] device mapper: Add builtin function dm_get_status()
> From: Christoph Hellwig [mailto:hch@...radead.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.
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
Powered by blists - more mailing lists