forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
93 lines
3.6 KiB
93 lines
3.6 KiB
========================================= |
|
rpcsec_gss support for kernel RPC servers |
|
========================================= |
|
|
|
This document gives references to the standards and protocols used to |
|
implement RPCGSS authentication in kernel RPC servers such as the NFS |
|
server and the NFS client's NFSv4.0 callback server. (But note that |
|
NFSv4.1 and higher don't require the client to act as a server for the |
|
purposes of authentication.) |
|
|
|
RPCGSS is specified in a few IETF documents: |
|
|
|
- RFC2203 v1: https://tools.ietf.org/rfc/rfc2203.txt |
|
- RFC5403 v2: https://tools.ietf.org/rfc/rfc5403.txt |
|
|
|
There is a third version that we don't currently implement: |
|
|
|
- RFC7861 v3: https://tools.ietf.org/rfc/rfc7861.txt |
|
|
|
Background |
|
========== |
|
|
|
The RPCGSS Authentication method describes a way to perform GSSAPI |
|
Authentication for NFS. Although GSSAPI is itself completely mechanism |
|
agnostic, in many cases only the KRB5 mechanism is supported by NFS |
|
implementations. |
|
|
|
The Linux kernel, at the moment, supports only the KRB5 mechanism, and |
|
depends on GSSAPI extensions that are KRB5 specific. |
|
|
|
GSSAPI is a complex library, and implementing it completely in kernel is |
|
unwarranted. However GSSAPI operations are fundementally separable in 2 |
|
parts: |
|
|
|
- initial context establishment |
|
- integrity/privacy protection (signing and encrypting of individual |
|
packets) |
|
|
|
The former is more complex and policy-independent, but less |
|
performance-sensitive. The latter is simpler and needs to be very fast. |
|
|
|
Therefore, we perform per-packet integrity and privacy protection in the |
|
kernel, but leave the initial context establishment to userspace. We |
|
need upcalls to request userspace to perform context establishment. |
|
|
|
NFS Server Legacy Upcall Mechanism |
|
================================== |
|
|
|
The classic upcall mechanism uses a custom text based upcall mechanism |
|
to talk to a custom daemon called rpc.svcgssd that is provide by the |
|
nfs-utils package. |
|
|
|
This upcall mechanism has 2 limitations: |
|
|
|
A) It can handle tokens that are no bigger than 2KiB |
|
|
|
In some Kerberos deployment GSSAPI tokens can be quite big, up and |
|
beyond 64KiB in size due to various authorization extensions attacked to |
|
the Kerberos tickets, that needs to be sent through the GSS layer in |
|
order to perform context establishment. |
|
|
|
B) It does not properly handle creds where the user is member of more |
|
than a few thousand groups (the current hard limit in the kernel is 65K |
|
groups) due to limitation on the size of the buffer that can be send |
|
back to the kernel (4KiB). |
|
|
|
NFS Server New RPC Upcall Mechanism |
|
=================================== |
|
|
|
The newer upcall mechanism uses RPC over a unix socket to a daemon |
|
called gss-proxy, implemented by a userspace program called Gssproxy. |
|
|
|
The gss_proxy RPC protocol is currently documented `here |
|
<https://fedorahosted.org/gss-proxy/wiki/ProtocolDocumentation>`_. |
|
|
|
This upcall mechanism uses the kernel rpc client and connects to the gssproxy |
|
userspace program over a regular unix socket. The gssproxy protocol does not |
|
suffer from the size limitations of the legacy protocol. |
|
|
|
Negotiating Upcall Mechanisms |
|
============================= |
|
|
|
To provide backward compatibility, the kernel defaults to using the |
|
legacy mechanism. To switch to the new mechanism, gss-proxy must bind |
|
to /var/run/gssproxy.sock and then write "1" to |
|
/proc/net/rpc/use-gss-proxy. If gss-proxy dies, it must repeat both |
|
steps. |
|
|
|
Once the upcall mechanism is chosen, it cannot be changed. To prevent |
|
locking into the legacy mechanisms, the above steps must be performed |
|
before starting nfsd. Whoever starts nfsd can guarantee this by reading |
|
from /proc/net/rpc/use-gss-proxy and checking that it contains a |
|
"1"--the read will block until gss-proxy has done its write to the file.
|
|
|