> On May 22, 2019, at 11:19 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Wed, 2019-05-22 at 10:54 -0400, Chuck Lever wrote: >> Hi Mimi- >> >> I'm working on a section of draft-ietf-nfsv4-integrity-measurement that >> discusses what kind of access permission is necessary to update a file's >> IMA metadata. This is needed because every NFS operation has an associated >> user ID -- an NFS server implementer needs to know which users are allowed >> to alter the IMA metadata. >> >> On Linux, because the metadata is stored in "security.ima", CAP_SYS_ADMIN >> is required. >> >> But on other NFS server implementations (ones that might not have a >> capabilities system), IMA metadata could be stored via a mechanism that >> does not require any special permission. >> >> And, it seems to me that if a user can alter the file content, there is >> no additional harm in her being allowed to update the IMA metadata. >> >> Is there an architectural reason, other than that Linux stores IMA metadata >> in a security.* xattr, for requiring a superuser privilege to update IMA >> metadata? > > security.ima may contain either a file hash or signature. The file > hash should be protected via security.evm.[1] Allowing anyone to > update the file hash would defeat its purpose. I wasn't thinking that anyone would be allowed to update the hash, but rather that a typical non-Linux NFS server might allow the file's owner to update it, for example, since it might store IMA metadata via a mechanism that does not require privilege. If privilege is a requirement, then the draft has to state it and a non- Linux NFS server implementation itself will have to enforce the privilege requirement explicitly. (For Linux that is done by the VFS's xattr code, not by the NFS server implementation). I need to understand this better so I can write it up in the draft. Can you further explain what "defeat its purpose" means? - If the hash is altered, the effect is the same as if the file content is altered. - If the hash is altered, security.evm (which is not exposed via NFS) would allow a local (non-NFS) accessor to notice the specific problem. Seems like the file content is protected in these cases even if the hash is altered arbitrarily. ie, unwanted alteration is detected and then someone has to restore the file content and hash. What am I missing? > Mimi > > [1] Refer to Roberto's proposed change "[PATCH 3/4] ima: don't ignore > INTEGRITY_UNKNOWN EVM status" Hm. I didn't entirely understand the patch description. Even so, what concerns me is that EVM metadata is not exposed to NFS clients in the current Linux NFS implementation. For NFS, then, either: - a Linux server (or any server that has a local IMA implementation) will have to validate an unsigned hash locally, and then the underlying network transport will have to guarantee hash integrity during transit via GSS krb5i, for example or - the the IMA metadata (here I mean what is stored in security.ima) will have to be cryptographically signed such that the signature is also stored in that metadata and not in security.evm so that it is visible to NFS clients Currently the draft assumes that the only deployment mode with NFS will be the latter option. -- Chuck Lever
