From: Mimi Zohar <firstname.lastname@example.org> To: James Bottomley <James.Bottomley@HansenPartnership.com>, Chuck Lever <email@example.com>, James Morris <firstname.lastname@example.org> Cc: Deven Bowers <email@example.com>, Pavel Machek <firstname.lastname@example.org>, Sasha Levin <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Paul Moore <firstname.lastname@example.org>, Jonathan Corbet <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Jann Horn <email@example.com>, firstname.lastname@example.org, Al Viro <email@example.com>, Jens Axboe <firstname.lastname@example.org>, email@example.com, open list <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, linux-fsdevel <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Date: Mon, 10 Aug 2020 13:57:40 -0400 Message-ID: <email@example.com> (raw) In-Reply-To: <1597079586.3966.34.camel@HansenPartnership.com> On Mon, 2020-08-10 at 10:13 -0700, James Bottomley wrote: > On Mon, 2020-08-10 at 12:35 -0400, Mimi Zohar wrote: > > On Mon, 2020-08-10 at 08:35 -0700, James Bottomley wrote: > [...] > > > > Up to now, verifying remote filesystem file integrity has been > > > > out of scope for IMA. With fs-verity file signatures I can at > > > > least grasp how remote file integrity could possibly work. I > > > > don't understand how remote file integrity with existing IMA > > > > formats could be supported. You might want to consider writing a > > > > whitepaper, which could later be used as the basis for a patch > > > > set cover letter. > > > > > > I think, before this, we can help with the basics (and perhaps we > > > should sort them out before we start documenting what we'll do). > > > > I'm not opposed to doing that, but you're taking this discussion in a > > totally different direction. The current discussion is about NFSv4 > > supporting the existing IMA signatures, not only fs-verity > > signatures. I'd like to understand how that is possible and for the > > community to weigh in on whether it makes sense. > > Well, I see the NFS problem as being chunk at a time, right, which is > merkle tree, or is there a different chunk at a time mechanism we want > to use? IMA currently verifies signature on open/exec and then > controls updates. Since for NFS we only control the client, we can't > do that on an NFS server, so we really do need verification at read > time ... unless we're threading IMA back to the NFS server? Yes. I still don't see how we can support the existing IMA signatures, which is based on the file data hash, unless the "chunk at a time mechanism" is not a tree, but linear. Mimi > > > > The first basic is that a merkle tree allows unit at a time > > > verification. First of all we should agree on the unit. Since we > > > always fault a page at a time, I think our merkle tree unit should > > > be a page not a block. Next, we should agree where the check gates > > > for the per page accesses should be ... definitely somewhere in > > > readpage, I suspect and finally we should agree how the merkle tree > > > is presented at the gate. I think there are three ways: > > > > > > 1. Ahead of time transfer: The merkle tree is transferred and > > > verified > > > at some time before the accesses begin, so we already have a > > > verified copy and can compare against the lower leaf. > > > 2. Async transfer: We provide an async mechanism to transfer > > > the > > > necessary components, so when presented with a unit, we check > > > the > > > log n components required to get to the root > > > 3. The protocol actually provides the capability of 2 (like the > > > SCSI > > > DIF/DIX), so to IMA all the pieces get presented instead of > > > IMA > > > having to manage the tree > > > > > > There are also a load of minor things like how we get the head > > > hash, which must be presented and verified ahead of time for each > > > of the above 3. > > > > > > I was under the impression that IMA support for fs-verity signatures > > would be limited to including the fs-verity signature in the > > measurement list and verifying the fs-verity signature. As fs- > > verity is limited to immutable files, this could be done on file > > open. fs-verity would be responsible for enforcing the block/page > > data integrity. From a local filesystem perspective, I think that > > is all that is necessary. > > The fs-verity use case is a bit of a crippled one because it's > immutable. I think NFS represents more the general case where you > can't rely on immutability and have to verify at chunk read time. If > we get chunk at a time working for NFS, it should work also for fs- > verity and we wouldn't need to have two special paths. > > I think, even for NFS we would only really need to log the open, so > same as you imagine for fs-verity. As long as the chunk read hashes > match, we can be silent because everything is going OK, so we only need > to determine what to do and log on mismatch (which isn't expected to > happen for fs-verity). > > > In terms of remote file systems, the main issue is transporting and > > storing the Merkle tree. As fs-verity is limited to immutable files, > > this could still be done on file open. > > Right, I mentioned that in my options ... we need some "supply > integrity" hook ... or possibly multiple hooks for a variety of > possible methods.
next prev parent reply index Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-28 21:36 Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 01/11] scripts: add ipe tooling to generate boot policy Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 02/11] security: add ipe lsm evaluation loop and audit system Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 03/11] security: add ipe lsm policy parser and policy loading Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 04/11] ipe: add property for trust of boot volume Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 05/11] fs: add security blob and hooks for block_device Deven Bowers 2020-07-28 22:22 ` Casey Schaufler 2020-07-28 22:40 ` Al Viro 2020-07-28 23:55 ` Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 06/11] dm-verity: move signature check after tree validation Deven Bowers 2020-07-28 21:50 ` Eric Biggers 2020-07-28 23:55 ` Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 07/11] dm-verity: add bdev_setsecurity hook for dm-verity signature Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 08/11] ipe: add property for signed dmverity volumes Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 09/11] dm-verity: add bdev_setsecurity hook for root-hash Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 10/11] documentation: add ipe documentation Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 10/12] ipe: add property for dmverity roothash Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 11/11] cleanup: uapi/linux/audit.h Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 11/12] documentation: add ipe documentation Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 12/12] cleanup: uapi/linux/audit.h Deven Bowers 2020-08-02 11:55 ` [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Pavel Machek 2020-08-02 14:03 ` Sasha Levin 2020-08-02 14:31 ` Pavel Machek 2020-08-02 16:43 ` [dm-devel] " James Bottomley 2020-08-04 16:07 ` Deven Bowers 2020-08-05 15:01 ` James Bottomley 2020-08-05 16:59 ` James Morris 2020-08-05 18:15 ` Mimi Zohar 2020-08-05 23:51 ` James Morris 2020-08-06 14:33 ` Mimi Zohar 2020-08-07 16:41 ` James Morris 2020-08-07 17:31 ` Mimi Zohar 2020-08-07 18:40 ` Mimi Zohar 2020-08-10 20:29 ` James Morris 2020-08-08 17:47 ` Chuck Lever 2020-08-09 17:16 ` Mimi Zohar 2020-08-10 15:35 ` James Bottomley 2020-08-10 16:35 ` Mimi Zohar 2020-08-10 17:13 ` James Bottomley 2020-08-10 17:57 ` Mimi Zohar [this message] 2020-08-10 23:36 ` Chuck Lever 2020-08-11 5:43 ` James Bottomley 2020-08-11 14:48 ` Chuck Lever 2020-08-11 15:32 ` James Bottomley 2020-08-11 19:30 ` Pavel Machek 2020-08-12 14:45 ` Chuck Lever 2020-08-11 15:53 ` James Bottomley 2020-08-12 14:15 ` Chuck Lever 2020-08-12 15:51 ` James Bottomley 2020-08-13 14:42 ` Chuck Lever 2020-08-13 15:10 ` James Bottomley 2020-08-14 14:21 ` Chuck Lever 2020-08-11 18:28 ` James Bottomley 2020-08-12 13:56 ` Chuck Lever 2020-08-12 15:42 ` James Bottomley 2020-08-13 14:21 ` Chuck Lever 2020-08-13 14:42 ` James Bottomley 2020-08-13 14:56 ` Chuck Lever 2020-08-11 21:03 ` James Morris 2020-08-12 14:18 ` Chuck Lever 2020-08-12 17:07 ` 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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=James.Bottomley@HansenPartnership.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
Linux-Integrity Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \ firstname.lastname@example.org public-inbox-index linux-integrity Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity AGPL code for this site: git clone https://public-inbox.org/public-inbox.git