From: James Bottomley <James.Bottomley@HansenPartnership.com> To: Mimi Zohar <zohar@linux.ibm.com>, Chuck Lever <chucklever@gmail.com>, James Morris <jmorris@namei.org> Cc: Deven Bowers <deven.desai@linux.microsoft.com>, Pavel Machek <pavel@ucw.cz>, Sasha Levin <sashal@kernel.org>, snitzer@redhat.com, dm-devel@redhat.com, tyhicks@linux.microsoft.com, agk@redhat.com, Paul Moore <paul@paul-moore.com>, Jonathan Corbet <corbet@lwn.net>, nramas@linux.microsoft.com, serge@hallyn.com, pasha.tatashin@soleen.com, Jann Horn <jannh@google.com>, linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>, Jens Axboe <axboe@kernel.dk>, mdsakib@microsoft.com, open list <linux-kernel@vger.kernel.org>, eparis@redhat.com, linux-security-module@vger.kernel.org, linux-audit@redhat.com, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-integrity@vger.kernel.org, jaskarankhurana@linux.microsoft.com Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Date: Mon, 10 Aug 2020 10:13:06 -0700 [thread overview] Message-ID: <1597079586.3966.34.camel@HansenPartnership.com> (raw) In-Reply-To: <4664ab7dc3b324084df323bfa4670d5bfde76e66.camel@linux.ibm.com> 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? > > 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. James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@hansenpartnership.com> To: Mimi Zohar <zohar@linux.ibm.com>, Chuck Lever <chucklever@gmail.com>, James Morris <jmorris@namei.org> Cc: snitzer@redhat.com, Deven Bowers <deven.desai@linux.microsoft.com>, dm-devel@redhat.com, tyhicks@linux.microsoft.com, Pavel Machek <pavel@ucw.cz>, Paul, agk@redhat.com, Sasha Levin <sashal@kernel.org>, Jonathan Corbet <corbet@lwn.net>, nramas@linux.microsoft.com, serge@hallyn.com, pasha.tatashin@soleen.com, Jann Horn <jannh@google.com>, linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>, Jens Axboe <axboe@kernel.dk>, mdsakib@microsoft.com, open list <linux-kernel@vger.kernel.org>, linux-security-module@vger.kernel.org, linux-audit@redhat.com, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-integrity@vger.kernel.org, jaskarankhurana@linux.microsoft.com Subject: Re: [dm-devel] [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Date: Mon, 10 Aug 2020 10:13:06 -0700 [thread overview] Message-ID: <1597079586.3966.34.camel@HansenPartnership.com> (raw) In-Reply-To: <4664ab7dc3b324084df323bfa4670d5bfde76e66.camel@linux.ibm.com> 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? > > 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. James -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-08-10 17:13 UTC|newest] Thread overview: 147+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-28 21:36 [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Deven Bowers 2020-07-28 21:36 ` Deven Bowers 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 ` 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 ` 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 ` Deven Bowers 2020-07-28 21:36 ` 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 ` 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 21:36 ` Deven Bowers 2020-07-28 22:22 ` Casey Schaufler 2020-07-28 22:22 ` Casey Schaufler 2020-07-28 22:40 ` Al Viro 2020-07-28 22:40 ` Al Viro 2020-07-28 23:55 ` Deven Bowers 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:36 ` Deven Bowers 2020-07-28 21:50 ` Eric Biggers 2020-07-28 21:50 ` Eric Biggers 2020-07-28 23:55 ` Deven Bowers 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 ` 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 ` 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 ` Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 10/11] documentation: add ipe documentation Deven Bowers 2020-07-28 21:36 ` 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 ` Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 11/11] cleanup: uapi/linux/audit.h Deven Bowers 2020-07-28 21:36 ` Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 11/12] documentation: add ipe documentation Deven Bowers 2020-07-28 21:36 ` Deven Bowers 2020-07-28 21:36 ` [RFC PATCH v5 12/12] cleanup: uapi/linux/audit.h Deven Bowers 2020-07-28 21:36 ` Deven Bowers 2020-08-02 11:55 ` [RFC PATCH v5 00/11] Integrity Policy Enforcement LSM (IPE) Pavel Machek 2020-08-02 11:55 ` Pavel Machek 2020-08-02 14:03 ` Sasha Levin 2020-08-02 14:03 ` Sasha Levin 2020-08-02 14:31 ` Pavel Machek 2020-08-02 14:31 ` Pavel Machek 2020-08-02 16:43 ` [dm-devel] " James Bottomley 2020-08-02 16:43 ` James Bottomley 2020-08-04 16:07 ` Deven Bowers 2020-08-04 16:07 ` Deven Bowers 2020-08-04 16:07 ` [dm-devel] " Deven Bowers 2020-08-05 15:01 ` James Bottomley 2020-08-05 15:01 ` James Bottomley 2020-08-05 15:01 ` [dm-devel] " James Bottomley 2020-08-05 16:59 ` James Morris 2020-08-05 16:59 ` James Morris 2020-08-05 18:15 ` Mimi Zohar 2020-08-05 18:15 ` Mimi Zohar 2020-08-05 23:51 ` James Morris 2020-08-05 23:51 ` James Morris 2020-08-06 14:33 ` Mimi Zohar 2020-08-06 14:33 ` Mimi Zohar 2020-08-06 14:33 ` Mimi Zohar 2020-08-07 16:41 ` James Morris 2020-08-07 16:41 ` James Morris 2020-08-07 17:31 ` Mimi Zohar 2020-08-07 17:31 ` Mimi Zohar 2020-08-07 18:40 ` Mimi Zohar 2020-08-07 18:40 ` Mimi Zohar 2020-08-10 20:29 ` James Morris 2020-08-10 20:29 ` James Morris 2020-08-08 17:47 ` Chuck Lever 2020-08-08 17:47 ` Chuck Lever 2020-08-09 17:16 ` Mimi Zohar 2020-08-09 17:16 ` Mimi Zohar 2020-08-10 15:35 ` James Bottomley 2020-08-10 15:35 ` James Bottomley 2020-08-10 16:35 ` Mimi Zohar 2020-08-10 16:35 ` Mimi Zohar 2020-08-10 17:13 ` James Bottomley [this message] 2020-08-10 17:13 ` James Bottomley 2020-08-10 17:57 ` Mimi Zohar 2020-08-10 17:57 ` Mimi Zohar 2020-08-10 23:36 ` Chuck Lever 2020-08-10 23:36 ` Chuck Lever 2020-08-10 23:36 ` Chuck Lever 2020-08-11 5:43 ` James Bottomley 2020-08-11 5:43 ` James Bottomley 2020-08-11 5:43 ` James Bottomley 2020-08-11 14:48 ` Chuck Lever 2020-08-11 14:48 ` Chuck Lever 2020-08-11 14:48 ` Chuck Lever 2020-08-11 15:32 ` James Bottomley 2020-08-11 15:32 ` James Bottomley 2020-08-11 15:32 ` James Bottomley 2020-08-11 19:30 ` Pavel Machek 2020-08-11 19:30 ` Pavel Machek 2020-08-11 19:30 ` Pavel Machek 2020-08-12 14:45 ` Chuck Lever 2020-08-12 14:45 ` Chuck Lever 2020-08-12 14:45 ` Chuck Lever 2020-08-11 15:53 ` James Bottomley 2020-08-11 15:53 ` James Bottomley 2020-08-11 15:53 ` James Bottomley 2020-08-12 14:15 ` Chuck Lever 2020-08-12 14:15 ` Chuck Lever 2020-08-12 14:15 ` Chuck Lever 2020-08-12 15:51 ` James Bottomley 2020-08-12 15:51 ` James Bottomley 2020-08-12 15:51 ` James Bottomley 2020-08-13 14:42 ` Chuck Lever 2020-08-13 14:42 ` Chuck Lever 2020-08-13 14:42 ` Chuck Lever 2020-08-13 15:10 ` James Bottomley 2020-08-13 15:10 ` James Bottomley 2020-08-13 15:10 ` James Bottomley 2020-08-14 14:21 ` Chuck Lever 2020-08-14 14:21 ` Chuck Lever 2020-08-14 14:21 ` Chuck Lever 2020-08-11 18:28 ` James Bottomley 2020-08-11 18:28 ` James Bottomley 2020-08-11 18:28 ` James Bottomley 2020-08-12 13:56 ` Chuck Lever 2020-08-12 13:56 ` Chuck Lever 2020-08-12 13:56 ` Chuck Lever 2020-08-12 15:42 ` James Bottomley 2020-08-12 15:42 ` James Bottomley 2020-08-12 15:42 ` James Bottomley 2020-08-13 14:21 ` Chuck Lever 2020-08-13 14:21 ` Chuck Lever 2020-08-13 14:21 ` Chuck Lever 2020-08-13 14:42 ` James Bottomley 2020-08-13 14:42 ` James Bottomley 2020-08-13 14:42 ` James Bottomley 2020-08-13 14:56 ` Chuck Lever 2020-08-13 14:56 ` Chuck Lever 2020-08-13 14:56 ` Chuck Lever 2020-08-11 21:03 ` James Morris 2020-08-11 21:03 ` James Morris 2020-08-11 21:03 ` James Morris 2020-08-12 14:18 ` Chuck Lever 2020-08-12 14:18 ` Chuck Lever 2020-08-12 14:18 ` Chuck Lever 2020-08-12 17:07 ` Deven Bowers 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 \ --in-reply-to=1597079586.3966.34.camel@HansenPartnership.com \ --to=james.bottomley@hansenpartnership.com \ --cc=agk@redhat.com \ --cc=axboe@kernel.dk \ --cc=chucklever@gmail.com \ --cc=corbet@lwn.net \ --cc=deven.desai@linux.microsoft.com \ --cc=dm-devel@redhat.com \ --cc=eparis@redhat.com \ --cc=jannh@google.com \ --cc=jaskarankhurana@linux.microsoft.com \ --cc=jmorris@namei.org \ --cc=linux-audit@redhat.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mdsakib@microsoft.com \ --cc=nramas@linux.microsoft.com \ --cc=pasha.tatashin@soleen.com \ --cc=paul@paul-moore.com \ --cc=pavel@ucw.cz \ --cc=sashal@kernel.org \ --cc=serge@hallyn.com \ --cc=snitzer@redhat.com \ --cc=tyhicks@linux.microsoft.com \ --cc=viro@zeniv.linux.org.uk \ --cc=zohar@linux.ibm.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.