On Fri, Mar 01, 2019 at 11:01:14AM -0500, Chuck Lever wrote: > > > > On Mar 1, 2019, at 10:04 AM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Mon, Feb 18, 2019 at 02:41:24PM -0500, Chuck Lever wrote: > >> > >> > >>> On Feb 18, 2019, at 2:32 PM, bfields@xxxxxxxxxxxx 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. > > I'm not clear, then. Are you proposing to control support for IMA labels > with the "security_labels" export option? Just security labels. I'd think it'd make sense to support IMA labels whenever IMA and NFSD_V4 are both turned on. --b.
