Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) =========================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) rpcsec_gss support for kernel RPC servers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) =========================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) This document gives references to the standards and protocols used to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) implement RPCGSS authentication in kernel RPC servers such as the NFS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) server and the NFS client's NFSv4.0 callback server.  (But note that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) NFSv4.1 and higher don't require the client to act as a server for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9) purposes of authentication.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) RPCGSS is specified in a few IETF documents:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)  - RFC2203 v1: https://tools.ietf.org/rfc/rfc2203.txt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)  - RFC5403 v2: https://tools.ietf.org/rfc/rfc5403.txt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) There is a third version that we don't currently implement:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)  - RFC7861 v3: https://tools.ietf.org/rfc/rfc7861.txt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) Background
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) The RPCGSS Authentication method describes a way to perform GSSAPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Authentication for NFS.  Although GSSAPI is itself completely mechanism
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) agnostic, in many cases only the KRB5 mechanism is supported by NFS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) implementations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) The Linux kernel, at the moment, supports only the KRB5 mechanism, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) depends on GSSAPI extensions that are KRB5 specific.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) GSSAPI is a complex library, and implementing it completely in kernel is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) unwarranted. However GSSAPI operations are fundementally separable in 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) parts:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) - initial context establishment
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) - integrity/privacy protection (signing and encrypting of individual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)   packets)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) The former is more complex and policy-independent, but less
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) performance-sensitive.  The latter is simpler and needs to be very fast.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) Therefore, we perform per-packet integrity and privacy protection in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) kernel, but leave the initial context establishment to userspace.  We
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) need upcalls to request userspace to perform context establishment.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) NFS Server Legacy Upcall Mechanism
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) The classic upcall mechanism uses a custom text based upcall mechanism
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) to talk to a custom daemon called rpc.svcgssd that is provide by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) nfs-utils package.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) This upcall mechanism has 2 limitations:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) A) It can handle tokens that are no bigger than 2KiB
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) In some Kerberos deployment GSSAPI tokens can be quite big, up and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) beyond 64KiB in size due to various authorization extensions attacked to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) the Kerberos tickets, that needs to be sent through the GSS layer in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) order to perform context establishment.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) B) It does not properly handle creds where the user is member of more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) than a few thousand groups (the current hard limit in the kernel is 65K
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) groups) due to limitation on the size of the buffer that can be send
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) back to the kernel (4KiB).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) NFS Server New RPC Upcall Mechanism
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) ===================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) The newer upcall mechanism uses RPC over a unix socket to a daemon
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) called gss-proxy, implemented by a userspace program called Gssproxy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) The gss_proxy RPC protocol is currently documented `here
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) <https://fedorahosted.org/gss-proxy/wiki/ProtocolDocumentation>`_.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) This upcall mechanism uses the kernel rpc client and connects to the gssproxy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) userspace program over a regular unix socket. The gssproxy protocol does not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) suffer from the size limitations of the legacy protocol.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) Negotiating Upcall Mechanisms
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) To provide backward compatibility, the kernel defaults to using the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) legacy mechanism.  To switch to the new mechanism, gss-proxy must bind
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) to /var/run/gssproxy.sock and then write "1" to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) /proc/net/rpc/use-gss-proxy.  If gss-proxy dies, it must repeat both
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) steps.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) Once the upcall mechanism is chosen, it cannot be changed.  To prevent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) locking into the legacy mechanisms, the above steps must be performed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) before starting nfsd.  Whoever starts nfsd can guarantee this by reading
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) from /proc/net/rpc/use-gss-proxy and checking that it contains a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) "1"--the read will block until gss-proxy has done its write to the file.