> 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? -- Chuck Lever
