Re: [PATCH RFC 4/4] NFSD: Prototype support for IMA on NFS (server)

From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	linux-integrity@vger.kernel.org
Subject: Re: [PATCH RFC 4/4] NFSD: Prototype support for IMA on NFS (server)
Date: Fri, 1 Mar 2019 10:04:01 -0500	[thread overview]
Message-ID: <20190301150401.GA17160@fieldses.org> (raw)
In-Reply-To: <A7D59BDC-08B3-4338-8E3B-6B41AC652968@oracle.com>

On Mon, Feb 18, 2019 at 02:41:24PM -0500, Chuck Lever wrote:
> 
> 
> > On Feb 18, 2019, at 2:32 PM, bfields@fieldses.org wrote:
> > 
> > On Thu, Feb 14, 2019 at 03:43:26PM -0500, Chuck Lever wrote:
> >> When NFSv4 Security Label support is enabled and kernel Integrity
> >> and IMA support is enabled (via CONFIG), then build in code to
> >> handle the "security.ima" xattr. The NFS server converts incoming
> >> GETATTR and SETATTR calls to acesses and updates of the xattr.
> >> 
> >> The FATTR4 bit is made up; meaning we still have to go through a
> >> standards process to allocate a bit that all NFS vendors agree on.
> >> Thus there is no guarantee this prototype will interoperate with
> >> others or with a future standards-based implementation.
> > 
> > Why the dependence on CONFIG_NFSD_V4_SECURITY_LABEL?
> 
> Hrm, well there is some mechanism on the client side that IMA
> needs that is behind CONFIG_NFS_V4_SECURITY_LABEL. I guess I
> didn't think about not doing the same thing on the server. It
> may just be an artifact of an earlier version of this code.
> 
> 
> > (Also, I wonder if we actually need CONFIG_NFSD_V4_SECURITY_LABEL or if
> > we could just remove it, or replace it by CONFIG_SECURITY where
> > necessary.)
> 
> On the server, there is already a (run-time) export option to
> enable and disable security labels. Is there a reason a
> distribution would want to disable client or server support
> for security labels at build time?

Distributions tend to want kernels that can do anything, with run time
controls that are adequate to handle any use cases.

So given that we need adequate run-time configuration, why might someone
also want the ability to disable at build time?  Some reasons I can
think of:

	- they need a really small kernel.
	- the feature is too hard to support, or they think it
	  introduces security risks, so they don't want their users
	  turning it on at all.

I could see any of those being reasons for someone not to want NFSD_V4
or SECURITY at all, but is there likely to be a big need to configure in
both of those things but configure out NFSD_V4_SECURITY_LABEL?  That
seems unnecessarily fine grained.

--b.