I'm in the middle of rewriting https://datatracker.ietf.org/doc/draft-cel-nfsv4-linux-seclabel-xtensions/ which was recently rejected by the nfsv4 Working Group for plausible and fixable reasons. They like the idea, but my proposal for using NFSv4 security labels is not workable even as an experiment. As I compose a fresh Internet-Draft I'm trying to understand what an EVM HMAC covers, and I found this: http://linux-ima.sourceforge.net/evmctl.1.html > EVM protects file metadata by including following attributes into HMAC and signature calculation: inode number, inode generation, UID, GID, file mode, security.selinux, security.SMACK64, security.ima, security.capability. > EVM HMAC and signature may also include additional file and file system attributes. Currently supported additional attributes are filesystem UUID and extra SMACK extended attributes. The computation of the IMA HMAC is straightforward, but it appears that the EVM HMAC is evolving, and not all of the input items would necessarily be visible to remote EVM consumers. Is there any way an NFS client would be able to tell exactly what attributes were used to compute an EVM hash, and what should it do if the whole input set is not available for verification? Amongst the security. xattrs, I believe only security.selinux is currently exposed via NFS. Thus an NFS client EVM would see only that particular xattr and not others by which it can compute or verify the EVM hash. Does the inclusion here of "security.capability" mean that NFS support for EVM and for file capabilities are inseparable? Is the content of security.capability in a binary or human-readable format? Filesystem attributes such as a UUID, type, or disk label might not be visible to NFS clients. Would there be any reason to protect ACLs with the EVM hash? -- Chuck Lever
