From: Mimi Zohar <zohar@linux.ibm.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Bruce Fields <bfields@fieldses.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
linux-integrity@vger.kernel.org,
"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH v2 3/5] NFSD: Remove ima_file_check call
Date: Thu, 21 Mar 2019 07:44:47 -0400 [thread overview]
Message-ID: <1553168687.4899.396.camel@linux.ibm.com> (raw)
In-Reply-To: <0E02D70A-A5E9-4B27-9922-521D5A0755A3@oracle.com>
On Wed, 2019-03-20 at 08:40 -0500, Chuck Lever wrote:
>
> > On Mar 19, 2019, at 3:29 PM, Mimi Zohar <zohar@linux.ibm.com> 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@fieldses.org> wrote:
> >>>
> >>> On Fri, Mar 08, 2019 at 04:11:06PM -0500, Chuck Lever wrote:
> >>>>
> >>>>
> >>>>> On Mar 8, 2019, at 4:10 PM, bfields@fieldses.org 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?
>
next prev parent reply other threads:[~2019-03-21 11:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-07 15:28 [PATCH v2 0/5] RFC: Linux IMA on NFS prototype Chuck Lever
2019-03-07 15:28 ` [PATCH v2 1/5] NFS: Define common IMA-related protocol elements Chuck Lever
2019-03-07 15:28 ` [PATCH v2 2/5] NFSD: Prototype support for IMA on NFS (server) Chuck Lever
2019-03-07 15:28 ` [PATCH v2 3/5] NFSD: Remove ima_file_check call Chuck Lever
2019-03-08 21:10 ` J. Bruce Fields
2019-03-08 21:11 ` Chuck Lever
2019-03-08 21:23 ` Bruce Fields
2019-03-08 21:29 ` Chuck Lever
2019-03-19 20:29 ` Mimi Zohar
2019-03-20 13:40 ` Chuck Lever
2019-03-21 11:44 ` Mimi Zohar [this message]
2019-03-21 14:04 ` Chuck Lever
2019-03-22 22:55 ` Mimi Zohar
2019-03-25 14:24 ` Chuck Lever
2019-03-25 15:01 ` Mimi Zohar
2019-03-07 15:28 ` [PATCH v2 4/5] NFS: Rename security xattr handler Chuck Lever
2019-03-07 15:29 ` [PATCH v2 5/5] NFS: Prototype support for IMA on NFS (client) Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1553168687.4899.396.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).