On Thu, Feb 21, 2019 at 10:58:49AM -0500, Chuck Lever wrote: > > > > On Feb 21, 2019, at 10:51 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > On Thu, 2019-02-21 at 09:49 -0500, Chuck Lever wrote: > >> > >>> On Feb 20, 2019, at 7:26 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > >>> > >>> On Tue, 2019-02-19 at 22:51 -0500, Chuck Lever wrote: > >>>>> On Feb 19, 2019, at 7:36 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> 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.) > > OK, glad to know NFS is not alone! > > We would need to guarantee that the file's absolute pathname as seen > by NFS clients is the same as its pathname as seen locally on the NFS > server. This wasn't true for NFSv3, but is usually true for NFSv4, > which exposes a pseudofilesystem root -- on many NFSv4 servers this > looks just like the real local filesystem missing any files that are > not shared. (NFS folks, feel free to chime in and tell me I'm wrong). That's very implementation-specific. Better to say something like "the pathname seen by the NFS client is the same as that in namespace the server exports". --b.
