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?
Please advise . . .
Regards,
Jeff Hunter
> On Dec 14, 2023, at 2:28 PM, Jeff Hunter <[email protected]> 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