On Wed, 2019-05-22 at 11:49 -0400, Chuck Lever wrote: > > > 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? Updating security.ima, or for that matter any other EVM protected security xattrs/file metadata, causes the security.evm HMAC to be recalculated and written, unless security.evm is a portable & immutable signature. To prevent against including other untrusted modifications from being included in the EVM HMAC, EVM first verifies the existing security.evm xattr is valid, before recalculating the HMAC and writing security.evm. The current design assumes that the file metadata would be included with the file data and distributed in software packages. The package installer is privileged and would install both the file data and metadata. In terms of writing security.ima, a similar problem exists in containers, when root in the container is not the system root. For NFS, in addition to the issue of security xattrs, we need to limit the permitted security.ima types. Mimi
