> 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). > 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. What is to be done about hard linked files? -- Chuck Lever
