[Cc'ing Roberto, Matthew for comment] On Thu, 2019-05-30 at 13:34 -0400, Chuck Lever wrote: > > > On May 23, 2019, at 9:25 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > 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). > > Thinking this through some more. Here's a common usage scenario. > > Suppose we have a NetApp filer that serves a small community of NFS > clients. Suppose the filer can store IMA metadata using the NFS extension > I describe in draft-ietf-nfsv4-integrity-measurement. But note some > things about this NFS server: > > o There is no user execution environment on that server. The only way > that file content is accessed is via NFS. > > o The server does not have any native support for IMA metadata. It > just stores the metadata blob, and does not otherwise interpret it. > > o There is no secondary (EVM) protection of the IMA metadata. > > In a software distribution scenario with an NFS server that does not > allow local (non-NFS) access to file contents, the clients must store > the file content and IMA metadata. > > Each NFS operation sent by any NFS client has a user ID associated with > it, including operations to store and retrieve IMA metadata. Obviously, > retrieving IMA metadata can be done by anyone on any client that is > allowed to access the server's exports. > > Typically the client passes update requests to the NFS server, which > is the final authority on when file content can be modified. The > question is, how does the server determine which clients and users > are allowed to modify IMA metadata? > > Assuming a client is simply running some kind of package tool to > install files on an NFS mount, there is no local signing key, so there > is no issue about the writing user requiring a privilege to sign > these file's IMA metadata. The metadata already exists. > > The server could authorize IMA metadata changes by user ID, or it could > allow only one of the clients to change IMA metadata. Another possibility > is to allow the file's ACL to determine who can update the metadata. > > What is most comparable to local access controls? > > My server prototype allows only the root user to update IMA metadata, on > any client that has write access to the export (controlled by /etc/exports). It's kind of ironic that Roberto's patch is requiring EVM, well only for mutable files, while your scenario doesn't support EVM. I agree with you that if you have permission to write the file data, that you should also have permission to write the file metadata. Since you're not interested in supporting EVM and are only interested in supporting signed files, this makes it a lot easier. IMA could be extended to allow the file metadata be stored in xattr namespaces other than security, based on policy. Mimi > > >> 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 > > -- > Chuck Lever > > >
