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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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.

--
Chuck Lever







[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux