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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

--
Chuck Lever






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux