Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9 |
|
#
99044c01 |
| 24-Dec-2023 |
Zhipeng Lu <alexious@zju.edu.cn> |
SUNRPC: fix a memleak in gss_import_v2_context
[ Upstream commit e67b652d8e8591d3b1e569dbcdfcee15993e91fa ]
The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_contex
SUNRPC: fix a memleak in gss_import_v2_context
[ Upstream commit e67b652d8e8591d3b1e569dbcdfcee15993e91fa ]
The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error.
Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.
Fixes: 47d848077629 ("gss_krb5: handle new context format from gssd") Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37 |
|
#
cfb6b328 |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove the ->import_ctx method
All supported encryption types now use the same context import function.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever
SUNRPC: Remove the ->import_ctx method
All supported encryption types now use the same context import function.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
6c922ea7 |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove CONFIG_RPCSEC_GSS_KRB5_CRYPTOSYSTEM
This code is now always on, so the ifdef can be removed.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@ora
SUNRPC: Remove CONFIG_RPCSEC_GSS_KRB5_CRYPTOSYSTEM
This code is now always on, so the ifdef can be removed.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
da33d635 |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove gss_import_v1_context()
We no longer support importing v1 contexts.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
#
ec596aaf |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove code behind CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED
None of this code can be enabled any more.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.
SUNRPC: Remove code behind CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED
None of this code can be enabled any more.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
2024b89d |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove DES and DES3 enctypes from the supported enctypes list
These enctypes can no longer be enabled via CONFIG.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <c
SUNRPC: Remove DES and DES3 enctypes from the supported enctypes list
These enctypes can no longer be enabled via CONFIG.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
Revision tags: v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7 |
|
#
ddd8c1f9 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Export get_gss_krb5_enctype()
I plan to add KUnit tests that will need enctype profile information. Export the enctype profile lookup function.
Tested-by: Scott Mayhew <smayhew@redhat.com>
SUNRPC: Export get_gss_krb5_enctype()
I plan to add KUnit tests that will need enctype profile information. Export the enctype profile lookup function.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
6e6d9eee |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Advertise support for the Camellia encryption types
Add the RFC 6803 encryption types to the string of integers that is reported to gssd during upcalls. This enables gssd to utilize keys wit
SUNRPC: Advertise support for the Camellia encryption types
Add the RFC 6803 encryption types to the string of integers that is reported to gssd during upcalls. This enables gssd to utilize keys with these encryption types when support for them is built into the kernel.
Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
45b4ef46 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add KDF_FEEDBACK_CMAC
The Camellia enctypes use the KDF_FEEDBACK_CMAC Key Derivation Function defined in RFC 6803 Section 3.
Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuc
SUNRPC: Add KDF_FEEDBACK_CMAC
The Camellia enctypes use the KDF_FEEDBACK_CMAC Key Derivation Function defined in RFC 6803 Section 3.
Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
3394682f |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Support the Camellia enctypes
RFC 6803 defines two encryption types that use Camellia ciphers (RFC 3713) and CMAC digests. Implement support for those in SunRPC's GSS Kerberos 5 mechanism.
SUNRPC: Support the Camellia enctypes
RFC 6803 defines two encryption types that use Camellia ciphers (RFC 3713) and CMAC digests. Implement support for those in SunRPC's GSS Kerberos 5 mechanism.
There has not been an explicit request to support these enctypes. However, this new set of enctypes provides a good alternative to the AES-SHA1 enctypes that are to be deprecated at some point.
As this implementation is still a "beta", the default is to not build it automatically.
Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
f26ec6b1 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Advertise support for RFC 8009 encryption types
Add the RFC 8009 encryption types to the string of integers that is reported to gssd during upcalls. This enables gssd to utilize keys with th
SUNRPC: Advertise support for RFC 8009 encryption types
Add the RFC 8009 encryption types to the string of integers that is reported to gssd during upcalls. This enables gssd to utilize keys with these encryption types when support for them is built into the kernel.
Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=400 Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
0d5b5a0f |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add RFC 8009 encryption and decryption functions
RFC 8009 enctypes use different crypt formulae than previous Kerberos 5 encryption types. Section 1 of RFC 8009 explains the reason for this
SUNRPC: Add RFC 8009 encryption and decryption functions
RFC 8009 enctypes use different crypt formulae than previous Kerberos 5 encryption types. Section 1 of RFC 8009 explains the reason for this change:
> The new types conform to the framework specified in [RFC3961], > but do not use the simplified profile, as the simplified profile > is not compliant with modern cryptographic best practices such as > calculating Message Authentication Codes (MACs) over ciphertext > rather than plaintext.
Add new .encrypt and .decrypt functions to handle this variation.
The new approach described above is referred to as Encrypt-then-MAC (or EtM). Hence the names of the new functions added here are prefixed with "krb5_etm_".
A critical second difference with previous crypt formulae is that the cipher state is included in the computed HMAC. Note however that for RPCSEC, the initial cipher state is easy to compute on both initiator and acceptor because it is always all zeroes.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
ae2e4d2b |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add KDF-HMAC-SHA2
The RFC 8009 encryption types use a different key derivation function than the RFC 3962 encryption types. The new key derivation function is defined in Section 3 of RFC 800
SUNRPC: Add KDF-HMAC-SHA2
The RFC 8009 encryption types use a different key derivation function than the RFC 3962 encryption types. The new key derivation function is defined in Section 3 of RFC 8009.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
a40cf753 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add gk5e definitions for RFC 8009 encryption types
Fill in entries in the supported_gss_krb5_enctypes array for the encryption types defined in RFC 8009. These new enctypes use the SHA-256 a
SUNRPC: Add gk5e definitions for RFC 8009 encryption types
Fill in entries in the supported_gss_krb5_enctypes array for the encryption types defined in RFC 8009. These new enctypes use the SHA-256 and SHA-384 message digest algorithms (as defined in FIPS-180) instead of the deprecated SHA-1 algorithm, and are thus more secure.
Note that NIST has scheduled SHA-1 for deprecation:
https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
Thus these new encryption types are placed under a separate CONFIG option to enable distributors to separately introduce support for the AES-SHA2 enctypes and deprecate support for the current set of AES-SHA1 encryption types as their user space allows.
As this implementation is still a "beta", the default is to not build it automatically.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
af664fc9 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add new subkey length fields
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 25
SUNRPC: Add new subkey length fields
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>
show more ...
|
#
8b3a09f3 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()
Although the Kerberos specs have always listed separate subkey lengths, the Linux kernel's SunRPC GSS Kerberos enctype profiles
SUNRPC: Parametrize the key length passed to context_v2_alloc_cipher()
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
ec4aaab3 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Clean up cipher set up for v1 encryption types
De-duplicate some common code.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lev
SUNRPC: Clean up cipher set up for v1 encryption types
De-duplicate some common code.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
2691a27d |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Hoist KDF into struct gss_krb5_enctype
Each Kerberos enctype can have a different KDF. Refactor the key derivation path to support different KDFs for the enctypes introduced in subsequent pa
SUNRPC: Hoist KDF into struct gss_krb5_enctype
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
ae6ad5d0 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
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: S
SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
d50b8152 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
Clean up: ->encrypt is set to only one value. Replace the two remaining call sites with direct calls to krb5_encrypt().
T
SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
dfe9a123 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES
Because the DES block cipher has been deprecated by Internet standard, highly secure configurations might require that DES support be
SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
17781b2c |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macro
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 flexi
SUNRPC: Replace KRB5_SUPPORTED_ENCTYPES macro
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
279a67cd |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove another switch on ctx->enctype
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: Scott Mayh
SUNRPC: Remove another switch on ctx->enctype
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
e01b2c79 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
Replace a number of switches on encryption type so that all of them don't have to be modified when adding or removing support
SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
8270dbfc |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Obscure Kerberos integrity keys
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 des
SUNRPC: Obscure Kerberos integrity keys
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: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|