All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org, linux-integrity@vger.kernel.org
Subject: Re: [PATCH RFC 0/4] IMA on NFS prototype
Date: Wed, 20 Feb 2019 07:26:36 -0500	[thread overview]
Message-ID: <1550665596.17768.32.camel@linux.ibm.com> (raw)
In-Reply-To: <ABC54315-2F2B-4FA7-98A8-28A3FC2092DB@oracle.com>

On Tue, 2019-02-19 at 22:51 -0500, Chuck Lever wrote:
> > On Feb 19, 2019, at 7:36 PM, Mimi Zohar <zohar@linux.ibm.com> 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.

Mimi


  reply	other threads:[~2019-02-20 12:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-14 20:43 [PATCH RFC 0/4] IMA on NFS prototype Chuck Lever
2019-02-14 20:43 ` [PATCH RFC 1/4] NFS: Define common IMA-related protocol elements Chuck Lever
2019-02-14 20:43 ` [PATCH RFC 2/4] NFS: Rename security xattr handler Chuck Lever
2019-02-14 20:43 ` [PATCH RFC 3/4] NFS: Prototype support for IMA on NFS (client) Chuck Lever
2019-02-14 20:43 ` [PATCH RFC 4/4] NFSD: Prototype support for IMA on NFS (server) Chuck Lever
2019-02-18 19:32   ` J. Bruce Fields
2019-02-18 19:41     ` Chuck Lever
2019-03-01 15:04       ` Bruce Fields
2019-03-01 16:01         ` Chuck Lever
2019-03-01 16:10           ` Bruce Fields
2019-02-20  0:36 ` [PATCH RFC 0/4] IMA on NFS prototype Mimi Zohar
2019-02-20  3:51   ` Chuck Lever
2019-02-20 12:26     ` Mimi Zohar [this message]
2019-02-21 14:49       ` Chuck Lever
2019-02-21 15:51         ` Mimi Zohar
2019-02-21 15:58           ` Chuck Lever
2019-02-22 20:16             ` J. Bruce Fields

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=1550665596.17768.32.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.