Re: [PATCH Version 5 00/17] RPCSEC_GSS3 full mode label kernel patch set

[Andy Adamson <androsadamson@gmail.com>]

On Thu, Mar 9, 2017 at 4:47 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Fri, Feb 24, 2017 at 05:19:36PM -0500, andros@netapp.com wrote:
>> From: Andy Adamson <andros@netapp.com>
>>
>> This patchset implements RFC 7861  RPCSEC_GSS Version 3 RPCSEC_GSS_CREATE
>> operation with rgs3_label payloads to provide  full mode Mandatory Access
>> Control (MAC) when run with NFSv4.2 Labeled NFS using SeLinux.
>
> Is GSSv3 also still planned to be used for COPY?  I lost track of that
> discussion.


Yes. I'm starting on that now.

-->Andy
>
> --b.
>
>>
>> A lot more testing is needed - and planned :)
>>
>> Client was built on Trond's testing branch, 4.10.0 kernel.
>> Server was  built on Bruce's nfsd-next branch, 4.10.0-rc7 kernel
>>
>> nfsd-next branch has these server required patches missing from Tronds
>> testing branch:
>>
>> 1) svcrpc: free contexts immediately on PROC_DESTROY
>> 2) nfsd: opt in to labeled nfs per export
>>
>> Version-5.
>> ---------
>> - responded to comments from Anna Schumaker
>> - refactored code to split generice RPCSEC_GSS_CREATE from label payload
>> - nfsd check for NFSEXP_SECURITY_LABEL export flag
>>
>> Requires on Client:
>> -------------------
>> gssd patches:  "RFC: GSSD changes for RPCSEC_GSS version 3"
>> libtirpc patches "RFC: Libtirpc changes for RPCSEC_GSS version 3"
>>
>> Implementation Features:
>> ------------------------
>>
>> GSSv3
>> - Negotiate GSS version - starts with GSSv3 then falls back to GSSv1 if
>>   GSSv3 is not supported.
>> - New GSSv3 reply verifier
>> - RPCSEC_GSS_CREATE operation generic code is separated from the payload code.
>> - rgss3_label assertion payload carries each client SeLinux thread label
>> - Supports one label assertion payload per RPCSEC_GSS_CREATE
>> - Kerberos pseudoflavor support (krb5, krb5i, krb5p)
>>
>> TODO:
>> ----
>> - Send all RPCSEC_GSS_CREATE calls with integrity or privacy
>> - Ensure SeLinux function exported in patch "SELINUX export
>>   security_current_sid_to_context" is OK with SeLinux experts.
>> - Perhaps add administrative ability on the client to indicate Full Mode
>>   MAC is desired and that NFSv4.2 Labeled NFS (LNFS) is used.
>>
>> Prototype description:
>> ---------------------
>> Parent GSS context: the normal GSS context
>>  - "Normal" GSSv3 context is the same as a "normal" GSSv1 context except
>>    for the new GSS Version and new reply verifier. For GSSv3 this "normal"
>>    context is called the parent context.
>>
>> Child GSS3 context: Is returned by a successful RPCSEC_GSS_CREATE operation
>>  - Child context is associated with the parent context on both the client
>>    and the server.
>>
>> If SeLinux is enabled and GSSv3 is in use, assume LNFS and GSSv3 full mode MAC.
>>
>> When Full Mode MAC is used:
>> - Each new GSS3 context (parent) kicks off an RPCSEC_GSS_CREATE with the
>> client thread's SeLinux label as a payload.
>>   - Upon success, the RPCSEC_GSS_CREATE call creates a GSSv3 child context
>>     handle that asserts the thread label, and uses the parent context for
>>     encrytion services.
>>   - CLIENT: Child context and assertion is stored in an assertion list
>>     off the struct gss_cl_ctx.
>>   - SERVER: Child context has it's own rsc cache entry, and the child
>>     handle is stored in a list of children handles off the parent rsc entry.
>>   - CLIENT and SERVER: child contexts are destroyed when parent context is
>>     destroyed.
>>   - CLIENT: child context associated with the client NFS request thread
>>     is used for the NFS request.
>>   - SERVER: Using the child context handle looks up the child rsc entry.
>>     Using the parent context handle stored in the child rsc entry looks up
>>     the parent rsc entry to use for MIC creation/verification, integrity
>>     (krb5i)  and/or privacy (krb5p).
>>   - SERVER: the label asserted by the NFS request child handle is imposed
>>     upon the NFSD thread servicing the request just like the UID/GIDs in
>>     the rpc credential.
>>
>> Each time a call is made, the client makes a check in gss_match to see if
>> the curren thread's SeLinux label has an associated GSS3 child context handle
>> to use. If not, an RPCSEC_GSS_CREATE call is kicked off to establish the
>> child context prior to the NFS request being sent. The NFS request then
>> uses the child context that asserts the client NFS request thread label
>> when sending the NFS request to the server.
>>
>> Smoke Test;
>> ----------
>> Setup:
>> - Ensure SeLinux is enabled on both client and server
>> - Turn on NFSv4.2 in client and server
>>   - SERVER: in /etc/sysconfig/nfs: RPCNFSDARGS="-V 4.2" (not needed in
>>     Fedora 25 as NFSv4.2 is turned on)
>>   - Fedora 25 SERVER export option "security_label" must be set:
>>     /export *(sec=krb5:sys,rw,no_subtree_check,no_root_squash,security_label)
>>   - CLIENT: mount -o v4.2 <server>:<export> <mntpoint>
>>   - Note: LNFS sends the file label in the OPEN compound GETATTR.
>>   - GSS3 sends the client thread label in the RPCSEC_GSS_CREATE call.
>> - Useful SeLinux commands
>>   - getenforce (setenforce) will let you know if Selinux is enforced
>>   - ls -Z  (shows label and fetches it via GETATTR usin LNFS)
>>   - ls -scontext  (shows just the label)
>>
>> Note: Server should be Fedora 25 as the nfs-utils-2.1.1.2.rc1.fc25 and
>> kernel 5.9.10-200.fc25 supports the new "security_label" export option
>> which needs to be set on an exported file system that wants to support
>> LNFS and GSS3 labels.
>>
>> Test: (run with wireshark capture)
>> Note: labels and conext values are from my setup. I restart gssd each test run.
>> Note: my server /etc/export is "/export *(sec=krb5:sys,rw,no_root_squash)"
>>
>> - # mount -o v4.2,sec=krb5 <server>:<export>  <mntpoint>
>>   # ls <mntpoint>
>>   - This will create a parent GSS context for kb5i (010000000000000 say 01),
>>     and a GSS3 child context for krb5i parent with the client thread
>>     label "system_u:system_r:kernel_t:s0" with handle 02.
>>    - The child handle 02 is used for the EXCHANGE_ID, CREATE_SESSION, and
>>      RECLAIM_COMPLETE calls.
>>   - Then a parent GSS handle is created for krb5 (03) and a GSS3 child
>>     context for the krb5 parent with hanel (04) for the client thread label
>>     "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"
>>    - The child handle 04 is used for the PUTROOT_FH, all the mount GETATTRs
>>      and the LOOKUP of "/export"
>>    - A new GSS3 child context (05) is created for krb5 parent with label
>>      "system_u:system_r:kernel_t:s0"
>>      The child handle 05 is used for LOOKUP, ACCESS, READDIR, etc.
>>
>>
>> - # umount <mntpoint>
>>    - This will create a new GSS3 child context (06) for krb5i parent with the
>>      client thread label
>>      "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"
>>     - The child handle 06 is used for DESTROY_SESSION and DESTROY_CLIENTID.
>>   - RPCSEC_GSS_DESTROY messages are sent for the two parent contexts 01 and 03.
>>   - CHILD: the parent contexts and associated child contexts are destroyed.
>>   - SERVER: the parent context and associated child contexts are destroyed.
>>
>> -->Andy
>>
>>
>> Andy Adamson (17):
>>   SUNRPC handle unsupported RPCSEC_GSS security service
>>   SUNRPC: RPCNULL call with payload for GSSv3
>>   SELINUX export security_current_sid_to_context
>>   SUNRPC GSSv3: base definitions
>>   SUNRPC AUTH_GSS get RPCSEC_GSS version from gssd downcall
>>   SUNRPC AUTH_GSS gss3 reply verifier
>>   SUNRPC AUTH_GSS RPCSEC_GSS_CREATE with no payload
>>   SUNRPC AUTH_GSS RPCSEC_GSS_CREATE with label payload
>>   SUNRPC AUTH_GSS store GSS3 assertions in parent gss_cl_ctx
>>   SUNRPC AUTH_GSS store and use gss3 label assertion
>>   SUNRPC AUTH_GSS free assertions
>>   SUNRPC: AUTH_GSS add RPC_GSS_PROC_CREATE case for wrap and unwrap
>>   SUNRPC SVCAUTH_GSS allow RPCSEC_GSS version 1 or 3
>>   SUNRPC SVCAUTH_GSS gss3 reply verifier
>>   SUNRPC SVCAUTH_GSS gss3 create label
>>   SUNRPC SVCAUTH_GSS set gss3 label on nfsd thread
>>   SUNRPC SVCAUTH_gss store gss3 child handles in parent rsc
>>
>>  fs/nfsd/auth.c                     |  11 +-
>>  include/linux/selinux.h            |   7 +
>>  include/linux/sunrpc/auth_gss.h    |  76 ++++-
>>  include/linux/sunrpc/clnt.h        |   3 +
>>  include/linux/sunrpc/gss_api.h     |  11 +
>>  include/linux/sunrpc/svcauth.h     |   1 +
>>  include/linux/sunrpc/svcauth_gss.h |   1 +
>>  net/sunrpc/auth_gss/auth_gss.c     | 564 ++++++++++++++++++++++++++++++++++++-
>>  net/sunrpc/auth_gss/svcauth_gss.c  | 549 ++++++++++++++++++++++++++++++++++--
>>  net/sunrpc/clnt.c                  |  20 ++
>>  security/selinux/hooks.c           |  14 +
>>  11 files changed, 1217 insertions(+), 40 deletions(-)
>>
>> --
>> 2.9.3
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html