* Re: IMA on remote file systems [not found] <C867A0BA-1ACF-4600-8179-3E15A098846C@oracle.com> @ 2019-09-13 14:50 ` Chuck Lever 2019-09-15 21:42 ` Mimi Zohar 0 siblings, 1 reply; 4+ messages in thread From: Chuck Lever @ 2019-09-13 14:50 UTC (permalink / raw) To: linux-integrity, linux-fsdevel Cc: Mimi Zohar, Michael Halcrow, Theodore Y. Ts'o, Matthew Garrett, Eric Biggers Resending ... > On Aug 28, 2019, at 1:36 PM, Chuck Lever <chuck.lever@oracle.com> wrote: > > Last week I presented at the Linux Security Summit on a proposal > for handling IMA metadata on NFS files. My proposal enables storage > of per-file IMA metadata via the NFSv4 protocol. I have a prototype > and an IETF nfsv4 Working Group document that specifies a small > protocol extension. > > After the presentation, Mimi Zohar pointed out that although the > proposal extends protection from an NFS file server to time-of- > measurement on an NFS client, there is still a protection gap between > time-of-measurement and time-of-use on that client. > > I would like to find a way to extend IMA protection all the way > to time-of-use on NFS clients. The consensus is that a per-file > Merkle tree would be the most desirable approach, as that is the > same mechanism used for fs-verity protection. > > For a few important reasons, it will be challenging to plumb > support for durable Merkle trees into NFS, although that is an > eventual goal. > > My thought was to use an ephemeral Merkle tree for NFS (and > possibly other remote filesystems, like FUSE, until these > filesystems support durable per-file Merkle trees). A tree would > be constructed when the client measures a file, but it would not > saved to the filesystem. Instead of a hash of the file's contents, > the tree's root signature is stored as the IMA metadata. > > Once a Merkle tree is available, it can be used in exactly the > same way that a durable Merkle tree would, to verify the integrity > of individual pages as they are used, evicted, and then read back > from the server. > > If the client needs to evict part or all of an ephemeral tree, it > can subsequently be reconstructed by measuring the file again and > verifying its root signature against the stored IMA metadata. > > So the only difference here is that the latency-to-first-byte > benefit of a durable Merkle tree would be absent. > > I'm interested in any thoughts or opinions about this approach. -- Chuck Lever ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IMA on remote file systems 2019-09-13 14:50 ` IMA on remote file systems Chuck Lever @ 2019-09-15 21:42 ` Mimi Zohar 2019-09-16 16:10 ` Theodore Y. Ts'o 0 siblings, 1 reply; 4+ messages in thread From: Mimi Zohar @ 2019-09-15 21:42 UTC (permalink / raw) To: Chuck Lever, linux-integrity, linux-fsdevel Cc: Michael Halcrow, Theodore Y. Ts'o, Matthew Garrett, Eric Biggers On Fri, 2019-09-13 at 10:50 -0400, Chuck Lever wrote: > Resending ... > > > On Aug 28, 2019, at 1:36 PM, Chuck Lever <chuck.lever@oracle.com> wrote: > > > > Last week I presented at the Linux Security Summit on a proposal > > for handling IMA metadata on NFS files. My proposal enables storage > > of per-file IMA metadata via the NFSv4 protocol. I have a prototype > > and an IETF nfsv4 Working Group document that specifies a small > > protocol extension. > > > > After the presentation, Mimi Zohar pointed out that although the > > proposal extends protection from an NFS file server to time-of- > > measurement on an NFS client, there is still a protection gap between > > time-of-measurement and time-of-use on that client. > > > > I would like to find a way to extend IMA protection all the way > > to time-of-use on NFS clients. The consensus is that a per-file > > Merkle tree would be the most desirable approach, as that is the > > same mechanism used for fs-verity protection. > > > > For a few important reasons, it will be challenging to plumb > > support for durable Merkle trees into NFS, although that is an > > eventual goal. > > > > My thought was to use an ephemeral Merkle tree for NFS (and > > possibly other remote filesystems, like FUSE, until these > > filesystems support durable per-file Merkle trees). A tree would > > be constructed when the client measures a file, but it would not > > saved to the filesystem. Instead of a hash of the file's contents, > > the tree's root signature is stored as the IMA metadata. > > > > Once a Merkle tree is available, it can be used in exactly the > > same way that a durable Merkle tree would, to verify the integrity > > of individual pages as they are used, evicted, and then read back > > from the server. > > > > If the client needs to evict part or all of an ephemeral tree, it > > can subsequently be reconstructed by measuring the file again and > > verifying its root signature against the stored IMA metadata. > > > > So the only difference here is that the latency-to-first-byte > > benefit of a durable Merkle tree would be absent. > > > > I'm interested in any thoughts or opinions about this approach. I like the idea, but there are a couple of things that need to happen first. Both fs-verity and IMA appended signatures need to be upstreamed. The IMA appended signature support simplifies ima_appraise_measurement(), paving the way for adding IMA support for other types of signature verification. How IMA will support fs-verity signatures still needs to be defined. That discussion will hopefully include NFS support. Mimi ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IMA on remote file systems 2019-09-15 21:42 ` Mimi Zohar @ 2019-09-16 16:10 ` Theodore Y. Ts'o 2019-09-16 18:16 ` Chuck Lever 0 siblings, 1 reply; 4+ messages in thread From: Theodore Y. Ts'o @ 2019-09-16 16:10 UTC (permalink / raw) To: Mimi Zohar Cc: Chuck Lever, linux-integrity, linux-fsdevel, Michael Halcrow, Theodore Y. Ts'o, Matthew Garrett, Eric Biggers On Sun, Sep 15, 2019 at 05:42:10PM -0400, Mimi Zohar wrote: > > > My thought was to use an ephemeral Merkle tree for NFS (and > > > possibly other remote filesystems, like FUSE, until these > > > filesystems support durable per-file Merkle trees). A tree would > > > be constructed when the client measures a file, but it would not > > > saved to the filesystem. Instead of a hash of the file's contents, > > > the tree's root signature is stored as the IMA metadata. > > > > > > Once a Merkle tree is available, it can be used in exactly the > > > same way that a durable Merkle tree would, to verify the integrity > > > of individual pages as they are used, evicted, and then read back > > > from the server. > > > > > > If the client needs to evict part or all of an ephemeral tree, it > > > can subsequently be reconstructed by measuring the file again and > > > verifying its root signature against the stored IMA metadata. Where would the client store the ephemeral tree? If you're thinking about storing in memory, calculating the emphemeral tree would require dragging the entire file across the network, which is going to be just as bad as using IMA --- plus the CPU cost of calculating the Merkle tree, and the memory cost of storing the ephemeral Merkle tree. I suspect that for most clients, it wouldn't be worth it unless the client can store the ephemeral tree *somewhere* on the client's local persistent storage, or maybe if it could store the Merkle tree on the NFS server (maybe via an xattr which contains the pathname to the Merkle tree relative to the NFS mount point?). > > > So the only difference here is that the latency-to-first-byte > > > benefit of a durable Merkle tree would be absent. What problem are you most interested in solving? And what cost do you think the user will be willing to pay in order to solve that problem? > I like the idea, but there are a couple of things that need to happen > first. Both fs-verity and IMA appended signatures need to be > upstreamed. Eric has sent the pull request fs-verity today. > The IMA appended signature support simplifies > ima_appraise_measurement(), paving the way for adding IMA support for > other types of signature verification. How IMA will support fs-verity > signatures still needs to be defined. That discussion will hopefully > include NFS support. As far as using the Merkle tree root hash for the IMA measurement, what sort of policy should be used for determining when the Merkle tree root hash should be used in preference to reading and checksuming the whole file when it is first opened? It could be as simple as, "if this is a fs-verity, use the fs-verity Merkle root". Is that OK? - Ted ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IMA on remote file systems 2019-09-16 16:10 ` Theodore Y. Ts'o @ 2019-09-16 18:16 ` Chuck Lever 0 siblings, 0 replies; 4+ messages in thread From: Chuck Lever @ 2019-09-16 18:16 UTC (permalink / raw) To: Theodore Y. Ts'o Cc: Mimi Zohar, linux-integrity, linux-fsdevel, Michael Halcrow, Theodore Y. Ts'o, Matthew Garrett, Eric Biggers > On Sep 16, 2019, at 12:10 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote: > > On Sun, Sep 15, 2019 at 05:42:10PM -0400, Mimi Zohar wrote: >>>> My thought was to use an ephemeral Merkle tree for NFS (and >>>> possibly other remote filesystems, like FUSE, until these >>>> filesystems support durable per-file Merkle trees). A tree would >>>> be constructed when the client measures a file, but it would not >>>> saved to the filesystem. Instead of a hash of the file's contents, >>>> the tree's root signature is stored as the IMA metadata. >>>> >>>> Once a Merkle tree is available, it can be used in exactly the >>>> same way that a durable Merkle tree would, to verify the integrity >>>> of individual pages as they are used, evicted, and then read back >>>> from the server. >>>> >>>> If the client needs to evict part or all of an ephemeral tree, it >>>> can subsequently be reconstructed by measuring the file again and >>>> verifying its root signature against the stored IMA metadata. > > Where would the client store the ephemeral tree? If you're thinking > about storing in memory, calculating the emphemeral tree would require > dragging the entire file across the network, which is going to be just > as bad as using IMA --- plus the CPU cost of calculating the Merkle > tree, and the memory cost of storing the ephemeral Merkle tree. A client would store ephemeral Merkle trees in memory. The most interesting use case to me is protecting executables and DLLs. These will tend to be limited in size, so the cost of Merkle tree construction should be nicely bounded in the typical case. An additional cost would arise if the in-memory tree were to be evicted. We hope that is an infrequent event. If the tree is partially evicted, only some of the file needs to be read back to re-construct it, since we would still have in-memory hashes stored in the interior nodes of the tree that enable the client to verify the portion of the tree that needs to be re-constructed. The short-term purpose of these trees is to add the value of better integrity protection for file systems that find it difficult to store per-file Merkle trees durably. We expect that situation will be temporary for many file systems, though not all. The price that is paid for this extra protection is that it will perform like traditional IMA, as you observed above. This is probably a different cost than reading from flash on a mobile device: a typical NFS client will be less memory- and CPU-constrained than a mobile device, and the cost of reading over NFS on a fast network from the server's cache is not high. The trade-offs here are going to be different. > I suspect that for most clients, it wouldn't be worth it unless the > client can store the ephemeral tree *somewhere* on the client's local > persistent storage, or maybe if it could store the Merkle tree on the > NFS server (maybe via an xattr which contains the pathname to the > Merkle tree relative to the NFS mount point?). The trees could be cached locally for exceptionally large files (eg files larger than the client's physical memory). For smaller files, which I expect will be the typical case, the cost of reading a file will be about the same as reading a Merkle tree. As mentioned in my proposal, the eventual goal is to extend the NFS protocol to store the Merkle tree durably on the server. We will get there eventually. Changing the protocol is a slow process, particularly because it involves consensus among NFS implementers who work on other operating systems besides Linux. >>>> So the only difference here is that the latency-to-first-byte >>>> benefit of a durable Merkle tree would be absent. > > What problem are you most interested in solving? And what cost do you > think the user will be willing to pay in order to solve that problem? NFS users would get full protection of their files from storage to point-of-use, at the same cost as IMA, until some point in the future when NFS can store the trees durably. The same would apply to other filesystems that find storing a full Merkle tree to be a challenge. >> I like the idea, but there are a couple of things that need to happen >> first. Both fs-verity and IMA appended signatures need to be >> upstreamed. > > Eric has sent the pull request fs-verity today. > >> The IMA appended signature support simplifies >> ima_appraise_measurement(), paving the way for adding IMA support for >> other types of signature verification. How IMA will support fs-verity >> signatures still needs to be defined. That discussion will hopefully >> include NFS support. > > As far as using the Merkle tree root hash for the IMA measurement, > what sort of policy should be used for determining when the Merkle > tree root hash should be used in preference to reading and checksuming > the whole file when it is first opened? It could be as simple as, "if > this is a fs-verity, use the fs-verity Merkle root". Is that OK? > > - Ted -- Chuck Lever ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-09-16 18:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <C867A0BA-1ACF-4600-8179-3E15A098846C@oracle.com> 2019-09-13 14:50 ` IMA on remote file systems Chuck Lever 2019-09-15 21:42 ` Mimi Zohar 2019-09-16 16:10 ` Theodore Y. Ts'o 2019-09-16 18:16 ` Chuck Lever
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).