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