- 20 Feb, 2023 40 commits
-
-
Chuck Lever authored
The aes256-cts-hmac-sha384-192 enctype specifies the length of its checksum and integrity subkeys as 192 bits, but the length of its encryption subkey (Ke) as 256 bits. Add new fields to struct gss_krb5_enctype that specify the key lengths individually, and where needed, use the correct new field instead of ->keylength. Tested-by:
Scott Mayhew <smayhew@redhat.com> Reviewed-by:
Simo Sorce <simo@redhat.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com>
-
Chuck Lever authored
Although the Kerberos specs have always listed separate subkey lengths, the Linux kernel's SunRPC GSS Kerberos enctype profiles assume the base key and the derived keys have identical lengths. The aes256-cts-hmac-sha384-192 enctype specifies the length of its checksum and integrity subkeys as 192 bits, but the length of its encryption subkey (Ke) as 256 bits. To support that enctype, parametrize context_v2_alloc_cipher() so that each of its call sites can pass in its desired key length. For now it will be the same length as before (gk5e->keylength), but a subsequent patch will change this. Tested-by:
-
Chuck Lever authored
De-duplicate some common code. Tested-by:
-
Chuck Lever authored
Each Kerberos enctype can have a different KDF. Refactor the key derivation path to support different KDFs for the enctypes introduced in subsequent patches. In particular, expose the key derivation function in struct gss_krb5_enctype instead of the enctype's preferred random-to-key function. The latter is usually the identity function and is only ever called during key derivation, so have each KDF call it directly. A couple of extra clean-ups: - Deduplicate the set_cdata() helper - Have ->derive_key return negative errnos, in accordance with usual kernel coding conventions This patch is a little bigger than I'd like, but these are all mechanical changes and they are all to the same areas of code. No behavior change is intended. Tested-by:
-
Chuck Lever authored
Clean up: there is now only one encrypt and only one decrypt method, thus there is no longer a need for the v2-suffixed method names. Tested-by:
-
Chuck Lever authored
Clean up: ->encrypt is set to only one value. Replace the two remaining call sites with direct calls to krb5_encrypt(). There have never been any call sites for the ->decrypt() method. Tested-by:
-
Chuck Lever authored
Because the DES block cipher has been deprecated by Internet standard, highly secure configurations might require that DES support be blacklisted or not installed. NFS Kerberos should still be able to work correctly with only the AES-based enctypes in that situation. Also note that MIT Kerberos has begun a deprecation process for DES encryption types. Their README for 1.19.3 states: > Beginning with the krb5-1.19 release, a warning will be issued > if initial credentials are acquired using the des3-cbc-sha1 > encryption type. In future releases, this encryption type will > be disabled by default and eventually removed. > > Beginning with the krb5-1.18 release, single-DES encryption > types have been removed. Aside from the CONFIG option name change, there are two important policy changes: 1. The 'insecure enctype' group is now disabled by default. Distributors have to take action to enable support for deprecated enctypes. Implementation of these enctypes will be removed in a future kernel release. 2. des3-cbc-sha1 is now considered part of the 'insecure enctype' group, having been deprecated by RFC 8429, and is thus disabled by default After this patch is applied, SunRPC support can be built with Kerberos 5 support but without CRYPTO_DES enabled in the kernel. And, when these enctypes are disabled, the Linux kernel's SunRPC RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649 and BCP 218 / RFC 8429. Tested-by:
-
Chuck Lever authored
Now that all consumers of the KRB5_SUPPORTED_ENCTYPES macro are within the SunRPC layer, the macro can be replaced with something private and more flexible. Tested-by:
-
Chuck Lever authored
Now that I've added a file under /proc/net/rpc that is managed by the SunRPC's Kerberos mechanism, replace NFSD's supported_krb5_enctypes file with a symlink to the new SunRPC proc file, which contains exactly the same content. Remarkably, commit b0b0c0a2 ("nfsd: add proc file listing kernel's gss_krb5 enctypes") added the nfsd_supported_krb5_enctypes file in 2011, but this file has never been documented in nfsd(7). Tested-by:
-
Chuck Lever authored
I would like to replace the KRB5_SUPPORTED_ENCTYPES macro so that there is finer granularity about what enctype support is built in to the kernel and then advertised by it. The /proc/fs/nfsd/supported_krb5_enctypes file is a legacy API that advertises supported enctypes to rpc.svcgssd (I think?). It simply prints the value of the KRB5_SUPPORTED_ENCTYPES macro, so it will need to be replaced with something that can instead display exactly which enctypes are configured and built into the SunRPC layer. Completely decommissioning such APIs is hard. Instead, add a file that is managed by SunRPC's GSS Kerberos mechanism, which is authoritative about enctype support status. A subsequent patch will replace /proc/fs/nfsd/supported_krb5_enctypes with a symlink to this new file. Tested-by:
-
Chuck Lever authored
Replace another switch on encryption type so that it does not have to be modified when adding or removing support for an enctype. Tested-by:
-
Chuck Lever authored
Replace a number of switches on encryption type so that all of them don't have to be modified when adding or removing support for an enctype. Tested-by:
-
Chuck Lever authored
There's no need to keep the integrity keys around if we instead allocate and key a pair of ahashes and keep those. This not only enables the subkeys to be destroyed immediately after deriving them, but it makes the Kerberos integrity code path more efficient. Tested-by:
-
Chuck Lever authored
There's no need to keep the signing keys around if we instead allocate and key an ahash and keep that. This not only enables the subkeys to be destroyed immediately after deriving them, but it makes the Kerberos signing code path more efficient. Tested-by:
-
Chuck Lever authored
The encryption subkeys are not used after the cipher transforms have been allocated and keyed. There is no need to retain them in struct krb5_ctx. Tested-by:
-
Chuck Lever authored
Hoist the name of the aux_cipher into struct gss_krb5_enctype to prepare for obscuring the encryption keys just after they are derived. Tested-by:
-
Chuck Lever authored
ctx->Ksess is never used after import has completed. Obscure it immediately so it cannot be re-used or copied. Tested-by:
-
Chuck Lever authored
Other common Kerberos implementations use a fully random confounder for encryption. The reason for this is explained in the new comment added by this patch. The current get_random_bytes() implementation does not exhaust system entropy. Since confounder generation is part of Kerberos itself rather than the GSS-API Kerberos mechanism, the function is renamed and moved. Note that light top-down analysis shows that the SHA-1 transform is by far the most CPU-intensive part of encryption. Thus we do not expect this change to result in a significant performance impact. However, eventually it might be necessary to generate an independent stream of confounders for each Kerberos context to help improve I/O parallelism. Reviewed-by:
-
Chuck Lever authored
Now that arcfour-hmac is gone, the confounder length is again the same as the cipher blocksize for every implemented enctype. The gss_krb5_enctype::conflen field is no longer necessary. Tested-by:
-
Chuck Lever authored
It is not clear from documenting comments, specifications, or code usage what value the gss_krb5_enctype.blocksize field is supposed to store. The "encryption blocksize" depends only on the cipher being used, so that value can be derived where it's needed instead of stored as a constant. RFC 3961 Section 5.2 says: > cipher block size, c > This is the block size of the block cipher underlying the > encryption and decryption functions indicated above, used for key > derivation and for the size of the message confounder and initial > vector. (If a block cipher is not in use, some comparable > parameter should be determined.) It must be at least 5 octets. > > This is not actually an independent parameter; rather, it is a > property of the functions E and D. It is listed here to clarify > the distinction between it and the message block size, m. In the Linux kernel's implemenation of the SunRPC RPCSEC GSS Kerberos 5 mechanism, the cipher block size, which is dependent on the encryption and decryption transforms, is used only in krb5_derive_key(), so it is straightforward to replace it. Tested-by:
-
Chuck Lever authored
Standard convention: Ensure the contents of the header are included only once per source file. Tested-by:
-
Chuck Lever authored
Eliminate the use of bus-locked operations in svc_xprt_enqueue(), which is a hot path. Replace them with per-cpu variables to reduce cross-CPU memory bus traffic. Signed-off-by: -
Chuck Lever authored
- Improves counting accuracy - Reduces cross-CPU memory traffic Signed-off-by: -
Jeff Layton authored
There's no need to start the reply cache before nfsd is up and running, and doing so means that we register a shrinker for every net namespace instead of just the ones where nfsd is running. Move it to the per-net nfsd startup instead. Reported-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Chuck Lever authored
Now that svcauth_gss_prepare_to_wrap() no longer computes the location of RPC header fields in the response buffer, svcauth_gss_accept() can save the location of the databody rather than the location of the verifier. Reviewed-by:
-
Chuck Lever authored
To navigate around the space that svcauth_gss_accept() reserves for the RPC payload body length and sequence number fields, svcauth_gss_release() does a little dance with the reply's accept_stat, moving the accept_stat value in the response buffer down by two words. Instead, let's have the ->accept() methods each set the proper final location of the accept_stat to avoid having to move things. Reviewed-by:
-
Chuck Lever authored
Currently, svcauth_gss_accept() pre-reserves response buffer space for the RPC payload length and GSS sequence number before returning to the dispatcher, which then adds the header's accept_stat field. The problem is the accept_stat field is supposed to go before the length and seq_num fields. So svcauth_gss_release() has to relocate the accept_stat value (see svcauth_gss_prepare_to_wrap()). To enable these fields to be added to the response buffer in the correct (final) order, the pointer to the accept_stat has to be made available to svcauth_gss_accept() so that it can set it before reserving space for the length and seq_num fields. As a first step, move the pointer to the location of the accept_stat field into struct svc_rqst. Reviewed-by:
-
Chuck Lever authored
The svc_get/put helpers are no longer used. Reviewed-by:
-
Chuck Lever authored
The @resv parameter is no longer used. Reviewed-by:
-
Chuck Lever authored
The main part of RPC header encoding and the formation of error responses are now done using the xdr_stream helpers. Bounds checking before each XDR data item is encoded makes the server's encoding path safer against accidental buffer overflows. Reviewed-by:
-
Chuck Lever authored
Now that each ->accept method has been converted, the svcxdr_init_encode() calls can be hoisted back up into the generic RPC server code. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
This code constructs replies to the decorated NULL procedure calls that establish GSS contexts. Convert this code path to use struct xdr_stream to encode such responses. Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
We're now moving svcxdr_init_encode() to /before/ the flavor's ->accept method has set rq_auth_slack. Add a helper that can set rq_auth_slack /after/ svcxdr_init_encode() has been called. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
Done as part of hardening the server-side RPC header encoding path. Reviewed-by:
-
Chuck Lever authored
Refactor: So that the overhaul of each ->accept method can be done in separate smaller patches, temporarily move the svcxdr_init_encode() call into those methods. Reviewed-by:
-
Chuck Lever authored
Now that all vs_dispatch functions invoke svcxdr_init_encode(), it is common code and can be pushed down into the generic RPC server. Reviewed-by:
-
Chuck Lever authored
RFC 5531 defines an MSG_ACCEPTED Reply message like this: struct accepted_reply { opaque_auth verf; union switch (accept_stat stat) { case SUCCESS: ... In the current server code, struct opaque_auth encoding is open- coded. Introduce a helper that encodes an opaque_auth data item within the context of a xdr_stream. Done as part of hardening the server-side RPC header decoding and encoding paths. Reviewed-by:
-
