> On Dec 14, 2023, at 2:28 PM, Jeff Hunter <wjhunter3@xxxxxxxxx> wrote: > > My apologies if this isn't the correct forum for this . . . > > Our customer desires to have Integrity Measurement Architecture (IMA) > values follow across NFS mounts. The linux kernel now supports xattr, > but only for user.* attributes. We've modified this to support > security.ima, but in doing so we've noticed that the xattr support in > NFS is very specific to user.* attributes. Was this done for a > reason? Is there a reason security.ima wasn't included? I looked at IMA support on NFS about 5 years ago, in concert with the Linux integrity community. NFS xattr support is only for the user. xattr namespace. The other namespaces store security-related or non-standard items and thus require specific NFS protocol elements to access. The semantics of non-user xattr content and the authorization to access and modify that content must be spelled out in an Internet standard. IMA has no such standard. But we do have Internet standards that describe ACLs and SELinux-related content. Those items can be accessed via NFS, though not directly as xattrs. Because IMA is part of Linux, it is covered by GPL. The NFS protocol, being an IETF standard, is covered by their licensing. Contributing the parts of IMA needed to support it in NFS would have required quite a bit of legal work. The alternative is inventing an IMA metadata type from scratch that is not already GPL-encumbered. Further, NFS servers are considered to be untrusted storage. An NFS client reads file data in small pieces. The data in each page read from an NFS server needs to be attested on the client. The current IMA metadata types do not adequately support per-page attestation. If you want to build a Linux-only implementation of IMA on NFS, you could do that by constructing a side protocol for accessing the security.ima content via RPC (ie, outside of the NFS protocol), similar to the way NFSACL works for NFSv3. Anyone can create this kind of RPC protocol, we just can't make it part of the NFS standard easily. You would then need to invent an IMA metadata type to store a Merkel tree or similar, or maybe just the root of such a tree, so that NFS clients could attest each page as it is read from the NFS server. If you don't want to do that, then you have to accept the ways that current IMA metadata is vulnerable, or accept painfully slow performance because the whole file has to be read each time any part of it is accessed. The compromises are many and I was never able to get traction in the NFS standards working group for supporting it. If your customer can live with the compromises, then perhaps you could implement something like I describe here. -- Chuck Lever
