> On May 22, 2018, at 9:07 AM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Tue, May 22, 2018 at 08:53:34AM -0700, Chuck Lever wrote: >> Hi- >> >> I'm continuing to look at NFS support for the Linux Integrity >> Measurement Architecture. >> >> When computing an HMAC hash of file attributes, sometimes the >> FS UUID is included. For a client to verify that hash, the >> server will have to expose that UUID somehow. >> >> Is there currently an NFSv4 attribute that carries the FS UUID? > > I think the fsid is as close as you get. > > Do you need to calculate hashes in exactly the way the server does? If > you're assuming a "dumb server" that just stores signatures without > interpreting them, then maybe not? The hashes have to be computed the same way everywhere, of course, whether it's on a client or on the server. Assuming that NFS were not in the picture, then the EVM hash would use the raw FS UUID. This is the hash that would be exposed to NFS clients if that filesystem were suddenly to be exported. So the NFS clients would need to have the same raw FS UUID in order to verify the hash. (And I'm actually not sure what benefit there is to including the FS UUID). I see two alternatives: -- Provide a new read-only filesystem attribute that exposes the FS UUID -- The FS UUID is optional. We could make it illegal to use the FS UUID in EVM hashes that will be exposed via NFS The bigger picture: - The input set for the hash contains optional items that will have to be given to remote EVM hash consumers. I think a new attribute that lists the set of hashed attributes will be necessary. - The input set can contain security.* xattrs, like security.SMACK64. These are currently not exposed to NFS clients, but not all files will have them. Not quite sure how to make that work generally. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
