2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2009-01-22 16:11:56 +08:00
|
|
|
config SUNRPC
|
|
|
|
|
tristate
|
kernel: conditionally support non-root users, groups and capabilities
There are a lot of embedded systems that run most or all of their
functionality in init, running as root:root. For these systems,
supporting multiple users is not necessary.
This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for
non-root users, non-root groups, and capabilities optional. It is enabled
under CONFIG_EXPERT menu.
When this symbol is not defined, UID and GID are zero in any possible case
and processes always have all capabilities.
The following syscalls are compiled out: setuid, setregid, setgid,
setreuid, setresuid, getresuid, setresgid, getresgid, setgroups,
getgroups, setfsuid, setfsgid, capget, capset.
Also, groups.c is compiled out completely.
In kernel/capability.c, capable function was moved in order to avoid
adding two ifdef blocks.
This change saves about 25 KB on a defconfig build. The most minimal
kernels have total text sizes in the high hundreds of kB rather than
low MB. (The 25k goes down a bit with allnoconfig, but not that much.
The kernel was booted in Qemu. All the common functionalities work.
Adding users/groups is not possible, failing with -ENOSYS.
Bloat-o-meter output:
add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 07:16:41 +08:00
|
|
|
depends on MULTIUSER
|
2009-01-22 16:11:56 +08:00
|
|
|
|
|
|
|
|
config SUNRPC_GSS
|
|
|
|
|
tristate
|
2013-03-17 03:54:52 +08:00
|
|
|
select OID_REGISTRY
|
kernel: conditionally support non-root users, groups and capabilities
There are a lot of embedded systems that run most or all of their
functionality in init, running as root:root. For these systems,
supporting multiple users is not necessary.
This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for
non-root users, non-root groups, and capabilities optional. It is enabled
under CONFIG_EXPERT menu.
When this symbol is not defined, UID and GID are zero in any possible case
and processes always have all capabilities.
The following syscalls are compiled out: setuid, setregid, setgid,
setreuid, setresuid, getresuid, setresgid, getresgid, setgroups,
getgroups, setfsuid, setfsgid, capget, capset.
Also, groups.c is compiled out completely.
In kernel/capability.c, capable function was moved in order to avoid
adding two ifdef blocks.
This change saves about 25 KB on a defconfig build. The most minimal
kernels have total text sizes in the high hundreds of kB rather than
low MB. (The 25k goes down a bit with allnoconfig, but not that much.
The kernel was booted in Qemu. All the common functionalities work.
Adding users/groups is not possible, failing with -ENOSYS.
Bloat-o-meter output:
add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-16 07:16:41 +08:00
|
|
|
depends on MULTIUSER
|
2009-01-22 16:11:56 +08:00
|
|
|
|
2011-07-14 07:20:49 +08:00
|
|
|
config SUNRPC_BACKCHANNEL
|
|
|
|
|
bool
|
|
|
|
|
depends on SUNRPC
|
|
|
|
|
|
2012-08-01 07:45:12 +08:00
|
|
|
config SUNRPC_SWAP
|
|
|
|
|
bool
|
|
|
|
|
depends on SUNRPC
|
|
|
|
|
|
2009-01-22 16:11:56 +08:00
|
|
|
config RPCSEC_GSS_KRB5
|
2011-04-16 00:58:56 +08:00
|
|
|
tristate "Secure RPC: Kerberos V mechanism"
|
2010-08-18 05:42:45 +08:00
|
|
|
depends on SUNRPC && CRYPTO
|
|
|
|
|
default y
|
2009-01-22 16:11:56 +08:00
|
|
|
select SUNRPC_GSS
|
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>
2023-01-16 01:21:52 +08:00
|
|
|
select CRYPTO_SKCIPHER
|
|
|
|
|
select CRYPTO_HASH
|
2009-01-22 16:11:56 +08:00
|
|
|
help
|
|
|
|
|
Choose Y here to enable Secure RPC using the Kerberos version 5
|
|
|
|
|
GSS-API mechanism (RFC 1964).
|
|
|
|
|
|
|
|
|
|
Secure RPC calls with Kerberos require an auxiliary user-space
|
|
|
|
|
daemon which may be found in the Linux nfs-utils package
|
|
|
|
|
available from http://linux-nfs.org/. In addition, user-space
|
|
|
|
|
Kerberos support should be installed.
|
|
|
|
|
|
2010-08-18 05:42:45 +08:00
|
|
|
If unsure, say Y.
|
2012-03-19 02:07:42 +08:00
|
|
|
|
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>
2023-01-16 01:21:52 +08:00
|
|
|
config RPCSEC_GSS_KRB5_SIMPLIFIED
|
|
|
|
|
bool
|
|
|
|
|
depends on RPCSEC_GSS_KRB5
|
|
|
|
|
|
|
|
|
|
config RPCSEC_GSS_KRB5_CRYPTOSYSTEM
|
|
|
|
|
bool
|
|
|
|
|
depends on RPCSEC_GSS_KRB5
|
|
|
|
|
|
|
|
|
|
config RPCSEC_GSS_KRB5_ENCTYPES_DES
|
|
|
|
|
bool "Enable Kerberos enctypes based on DES (deprecated)"
|
2019-02-12 00:24:43 +08:00
|
|
|
depends on RPCSEC_GSS_KRB5
|
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>
2023-01-16 01:21:52 +08:00
|
|
|
depends on CRYPTO_CBC && CRYPTO_CTS && CRYPTO_ECB
|
|
|
|
|
depends on CRYPTO_HMAC && CRYPTO_MD5 && CRYPTO_SHA1
|
|
|
|
|
depends on CRYPTO_DES
|
2019-02-12 00:24:43 +08:00
|
|
|
default n
|
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>
2023-01-16 01:21:52 +08:00
|
|
|
select RPCSEC_GSS_KRB5_SIMPLIFIED
|
|
|
|
|
help
|
|
|
|
|
Choose Y to enable the use of deprecated Kerberos 5
|
|
|
|
|
encryption types that utilize Data Encryption Standard
|
|
|
|
|
(DES) based ciphers. These include des-cbc-md5,
|
|
|
|
|
des-cbc-crc, and des-cbc-md4, which were deprecated by
|
|
|
|
|
RFC 6649, and des3-cbc-sha1, which was deprecated by RFC
|
|
|
|
|
8429.
|
|
|
|
|
|
|
|
|
|
These encryption types are known to be insecure, therefore
|
|
|
|
|
the default setting of this option is N. Support for these
|
|
|
|
|
encryption types is available only for compatibility with
|
|
|
|
|
legacy NFS client and server implementations.
|
|
|
|
|
|
|
|
|
|
Removal of support is planned for a subsequent kernel
|
|
|
|
|
release.
|
|
|
|
|
|
|
|
|
|
config RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1
|
|
|
|
|
bool "Enable Kerberos enctypes based on AES and SHA-1"
|
|
|
|
|
depends on RPCSEC_GSS_KRB5
|
|
|
|
|
depends on CRYPTO_CBC && CRYPTO_CTS
|
|
|
|
|
depends on CRYPTO_HMAC && CRYPTO_SHA1
|
|
|
|
|
depends on CRYPTO_AES
|
|
|
|
|
default y
|
|
|
|
|
select RPCSEC_GSS_KRB5_CRYPTOSYSTEM
|
2019-02-12 00:24:43 +08:00
|
|
|
help
|
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>
2023-01-16 01:21:52 +08:00
|
|
|
Choose Y to enable the use of Kerberos 5 encryption types
|
|
|
|
|
that utilize Advanced Encryption Standard (AES) ciphers and
|
|
|
|
|
SHA-1 digests. These include aes128-cts-hmac-sha1-96 and
|
|
|
|
|
aes256-cts-hmac-sha1-96.
|
2019-02-12 00:24:43 +08:00
|
|
|
|
2023-01-16 01:22:43 +08:00
|
|
|
config RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2
|
|
|
|
|
bool "Enable Kerberos enctypes based on AES and SHA-2"
|
|
|
|
|
depends on RPCSEC_GSS_KRB5
|
|
|
|
|
depends on CRYPTO_CBC && CRYPTO_CTS
|
|
|
|
|
depends on CRYPTO_HMAC && CRYPTO_SHA256 && CRYPTO_SHA512
|
|
|
|
|
depends on CRYPTO_AES
|
|
|
|
|
default n
|
|
|
|
|
select RPCSEC_GSS_KRB5_CRYPTOSYSTEM
|
|
|
|
|
help
|
|
|
|
|
Choose Y to enable the use of Kerberos 5 encryption types
|
|
|
|
|
that utilize Advanced Encryption Standard (AES) ciphers and
|
|
|
|
|
SHA-2 digests. These include aes128-cts-hmac-sha256-128 and
|
|
|
|
|
aes256-cts-hmac-sha384-192.
|
|
|
|
|
|
2012-03-19 02:07:42 +08:00
|
|
|
config SUNRPC_DEBUG
|
|
|
|
|
bool "RPC: Enable dprintk debugging"
|
|
|
|
|
depends on SUNRPC && SYSCTL
|
2014-11-27 03:44:43 +08:00
|
|
|
select DEBUG_FS
|
2012-03-19 02:07:42 +08:00
|
|
|
help
|
|
|
|
|
This option enables a sysctl-based debugging interface
|
|
|
|
|
that is be used by the 'rpcdebug' utility to turn on or off
|
|
|
|
|
logging of different aspects of the kernel RPC activity.
|
|
|
|
|
|
|
|
|
|
Disabling this option will make your kernel slightly smaller,
|
|
|
|
|
but makes troubleshooting NFS issues significantly harder.
|
|
|
|
|
|
|
|
|
|
If unsure, say Y.
|
2014-03-19 07:45:47 +08:00
|
|
|
|
2015-06-04 23:21:42 +08:00
|
|
|
config SUNRPC_XPRT_RDMA
|
|
|
|
|
tristate "RPC-over-RDMA transport"
|
2018-05-26 05:29:59 +08:00
|
|
|
depends on SUNRPC && INFINIBAND && INFINIBAND_ADDR_TRANS
|
2014-03-19 07:45:47 +08:00
|
|
|
default SUNRPC && INFINIBAND
|
2017-04-10 01:06:16 +08:00
|
|
|
select SG_POOL
|
2014-03-19 07:45:47 +08:00
|
|
|
help
|
2015-06-04 23:21:42 +08:00
|
|
|
This option allows the NFS client and server to use RDMA
|
|
|
|
|
transports (InfiniBand, iWARP, or RoCE).
|
2014-03-19 07:45:47 +08:00
|
|
|
|
2015-06-04 23:21:42 +08:00
|
|
|
To compile this support as a module, choose M. The module
|
|
|
|
|
will be called rpcrdma.ko.
|
2014-03-19 07:45:47 +08:00
|
|
|
|
2015-06-04 23:21:42 +08:00
|
|
|
If unsure, or you know there is no RDMA capability on your
|
|
|
|
|
hardware platform, say N.
|