On Wed, 2019-03-20 at 08:40 -0500, Chuck Lever wrote: > > > On Mar 19, 2019, at 3:29 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > On Fri, 2019-03-08 at 16:29 -0500, Chuck Lever wrote: > > > > Thanks Serge for bringing this thread to my attention. Sorry for the > > delay in responding ... > > > >>> On Mar 8, 2019, at 4:23 PM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > >>> > >>> On Fri, Mar 08, 2019 at 04:11:06PM -0500, Chuck Lever wrote: > >>>> > >>>> > >>>>> On Mar 8, 2019, at 4:10 PM, bfields@xxxxxxxxxxxx wrote: > >>>>> > >>>>> On Thu, Mar 07, 2019 at 10:28:54AM -0500, Chuck Lever wrote: > >>>>>> The NFS server needs to allow NFS clients to perform their own > >>>>>> attestation and measurement. > > > > Measurement and attestation is only one aspect. The other aspect is > > verifying the integrity of files. Shouldn't the NFS server verify the > > integrity of a file before allowing it to be served (eg. malware)? > > Hi Mimi, thanks for the review. > > Architecturally, the server is not using the file's data, it is > merely part of the filesystem that stores it. But that said, there > are several concrete reasons why I feel an NFS server should not be > involved in measurement/attestation, but only with storing file > content and IMA metadata. "Remote attestation" is the process of verifying the measurement list against the TPM PCRs, based on a TPM quote. I think you meant "measurement/appraisal". > > 1. The broadest attack surface for a remote filesystem is modification > of data in flight. Attestation of the file on the server is not going > to defend against that attack, only attestation on the client will do > that. Is there a good reason to pay the cost of double attestation? Doesn't the server have a responsibility to provide files that have not been unintentionally or maliciously altered? > 2. It is possible (perhaps even likely) that the NFS server and a > client of that server will have different IMA policies and even > different file signing authorities. That doesn't negate the due diligence on the server's part of preventing the spread of malware. > > A third, perhaps related, reason is that NFS can run on non-Linux NFS > servers which would not have any attestation at all. An NFS client > should not have to rely on the server for attestation, but should > trust only its own measurement of each file, which would be done as > late as possible before use. The ima_file_check() hook can also audit the file, providing additional forensic information (eg. the file hash). Mimi > > Lastly, the NFS protocol does not enable an NFS client to tell a > server how the file is to be used. For example, the server's policy > might block execution of an unverifiable file, but the server won't > have any way of knowing how the client is going to use that file. > The client might be opening the file to copy it or update its IMA > metadata. > > Speaking of protocol, there's no special error code that reports an > integrity verification failure. The client just sees that the UID > does not have access to the file. There's no way the user or client > can do anything to clear this condition via NFS without IMA support. > > If these reasons make sense, should I add them to the patch description? >
