Re: [PATCH RFC 0/4] IMA on NFS prototype

[Mimi Zohar <zohar@linux.ibm.com>]

On Thu, 2019-02-21 at 09:49 -0500, Chuck Lever wrote:
> 
> > On Feb 20, 2019, at 7:26 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Tue, 2019-02-19 at 22:51 -0500, Chuck Lever wrote:
> >>> On Feb 19, 2019, at 7:36 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> Hi Chuck,
> >>> 
> >>>> EVM is not supported in this prototype. NFS does not support several
> >>>> of the xattrs that are protected by EVM: SMACK64, Posix ACLs, and
> >>>> Linux file capabilities are not supported, which makes EVM more
> >>>> difficult to support on NFS mounts.
> >>> 
> >>> There's no requirement for all of these xattrs to exist.  If an xattr
> >>> does exist, then it is included in the security.evm hmac/signature.
> >> 
> >> Understood. The issue is that if they exist on a file residing on an NFS server,
> >> such xattrs would not be visible to clients. My understanding is that then EVM
> >> verification would fail on such files on NFS clients.
> >> 
> >> We could possibly make EVM work in limited scenarios until such time that
> >> the NFS protocol can make those xattrs available to NFS clients. I hope that
> >> having only security.ima is useful at least for experimenting and maybe more.
> >> 
> >> However, if folks think having security.evm also is needed, that is straight-
> >> forward... just saying that there are currently other limits in NFS that make a
> >> full EVM implementation problematic.
> > 
> > Thank you for the explanation.  Yes, I think there is a benefit of
> > having a file signature, without EVM.
> 
> It's been pointed out to me that a malicious actor inserted between
> an NFS server and an NFS client can concurrently substitute the IMA
> signature and a file's content with that of another file on the same
> NFS share.
> 
> This could be used to substitute /etc/group for /etc/passwd, for
> example. Both files are unchanged and have verifiable IMA signatures.
> The /etc/group file contains a passwd-like entry for root in it, but
> without a password field. That would allow the actor to gain root
> access on the NFS client.
> 
> NFS can mitigate this substitution by using Kerberos 5 integrity to
> protect wire traffic from tampering. However, a malicious NFS server
> could also perform this substitution, and krb5i would not be able to
> detect it.
> 
> I'm wondering if there's a mechanism within IMA's toolset to detect
> such a substitution on an NFS client.

This problem isn't limited to NFS, but is a general problem.  The file
name is part of the directory information, which would need to be
protected all the way up to root. (Dmitry's directory patches protects
one level of the directory tree.)

At last years LSF/MM, Allison Henderson gave a talk titled "XFS parent
pointers" - https://lwn.net/Articles/753480/.  After Allison's talk,
instead of protecting the entire filesystem directory hierarchy, Boaz
Harrosh suggested including the XFS parent pointers' pathname, stored
as an xattr, in the set of EVM protected xattrs.

Mimi