On Thu, Jan 25, 2018 at 01:49:06PM -0800, Chuck Lever wrote:
> > On Jan 25, 2018, at 11:11 AM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> >
> > I'd like to talk about a proposal to implement and upstream something
> > that we've been calling fs-verity, which is something like dm-verity,
> > but implemnted on a per-file basis. It will be implemnted much like
> > fs/crypto, in that most of the code will be in a generic layer, with
> > minimal modifications needed in the file system layer.
>
> I’m interested in this topic, specifically how we can support
> binary signing of executable code stored in NFS files.
The challenge for NFS is in the current design, the local disk file
system has to have a way to indicate that a particular file is playing
the fs-verity game. This is the "fsverity bit"; and so either the NFS
server is going to need to store this bit somewhere for you (which
probably means an extension to the NFS protcol, which is probably out
of scope) --- or you need to store a list of files which are assumed
to have fs-verity on the client.
I suppose you *could* have a magic mount option which says that any
file which is executable should be checked to see if it has the
fs-verity information at the end --- but this means relying on in-band
signalling and that is always fraught with potential false positives.
> I’m not expert by any means, but this is also different than IMA
> in that it avoids the use of a trusted extended attribute. The NFS
> protocol has no support for system/trusted xattrs, currently.
Yes, we don't use at trusted extended attribute.
> However, I suspect each file system might prefer to store the
> tree in its own way. And distributed file systems will have the
> additional challenge of protecting this metadata as it is in
> flight from file server to client.
Well, the root of the merkle tree will be signed by a PKCS11 digtial
signature, so the protection is built into fs-verity mechanism. The
original plan was that the protected file would look like this:
+------------------+
| File Data |
| ... |
+------------------+ <----- i_size
| FS Verity header |
+------------------+
| PKCS 11 signature|
+------------------+
| Merkle tree |
| ... |
+------------------+
| FS Verity header |
| (copy) |
+------------------+
This would be the same across all file systems, and all of the logic
for supporting this would be in fs/verity. An ioctl would cause the
local disk file system to set the FS Verity bit, and change i_size to
be located at the end of the file data (the value would be in the FS
Verity header; the FS Verity would begin on the next PAGE_SIZE offset
from the end of the file data).
So all the local disk file system would have to provide is (a) a way
to set and get the Verity bit, and (b) a way to read beyond i_size to
fetch the FS Verity information.
If you want to do this only in the NFS Client, without needing any
special NFS server support, assuming that you know this file is
playing the FS Verity game (e.g., maybe you use the executable bit as
a hint that you should try to find the FS Verity header), the NFS
client can try to read the last PAGE_SIZE block from the disk, and see
if it looks like a valid FS Verity header. If so, it can then check
to see if the copy located at the beginning of the FS Verity
information matches the one at the end of the file, and then spoof the
reported i_size reported to userspace via stat(2). All subsequent
processing would be the same as for a local disk file system; NFS
would just provide its own routing for "reading beyond i_size", which
would just involve sending the standard NFS read operation to the server.
So yeah, I think we could make this work. There might be a few
details, but I think we can make it work.
- Ted
