2019-05-19 13:07:45 +01:00
# SPDX-License-Identifier: GPL-2.0-only
2009-01-22 11:11:56 +03: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-15 16:16:41 -07:00
depends on MULTIUSER
2009-01-22 11:11:56 +03:00
config SUNRPC_GSS
tristate
2013-03-16 15:54:52 -04: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-15 16:16:41 -07:00
depends on MULTIUSER
2009-01-22 11:11:56 +03:00
2011-07-13 19:20:49 -04:00
config SUNRPC_BACKCHANNEL
bool
depends on SUNRPC
2012-07-31 16:45:12 -07:00
config SUNRPC_SWAP
bool
depends on SUNRPC
2009-01-22 11:11:56 +03:00
config RPCSEC_GSS_KRB5
2011-04-15 12:58:56 -04:00
tristate "Secure RPC: Kerberos V mechanism"
2010-08-17 17:42:45 -04:00
depends on SUNRPC && CRYPTO
default y
2009-01-22 11:11:56 +03: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-15 12:21:52 -05:00
select CRYPTO_SKCIPHER
select CRYPTO_HASH
2009-01-22 11:11:56 +03: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-17 17:42:45 -04:00
If unsure, say Y.
2012-03-18 14:07:42 -04: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-15 12:21:52 -05:00
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
2019-02-11 11:24:43 -05: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-15 12:21:52 -05: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-11 11:24:43 -05:00
2023-01-15 12:23:08 -05:00
config RPCSEC_GSS_KRB5_ENCTYPES_CAMELLIA
bool "Enable Kerberos encryption types based on Camellia and CMAC"
depends on RPCSEC_GSS_KRB5
depends on CRYPTO_CBC && CRYPTO_CTS && CRYPTO_CAMELLIA
depends on CRYPTO_CMAC
default n
help
Choose Y to enable the use of Kerberos 5 encryption types
that utilize Camellia ciphers (RFC 3713) and CMAC digests
(NIST Special Publication 800-38B). These include
camellia128-cts-cmac and camellia256-cts-cmac.
2023-01-15 12:22:43 -05: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
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.
2023-01-15 12:23:34 -05:00
config RPCSEC_GSS_KRB5_KUNIT_TEST
tristate "KUnit tests for RPCSEC GSS Kerberos" if !KUNIT_ALL_TESTS
depends on RPCSEC_GSS_KRB5 && KUNIT
default KUNIT_ALL_TESTS
help
This builds the KUnit tests for RPCSEC GSS Kerberos 5.
KUnit tests run during boot and output the results to the debug
log in TAP format (https://testanything.org/). Only useful for
kernel devs running KUnit test harness and are not for inclusion
into a production build.
For more information on KUnit and unit tests in general, refer
to the KUnit documentation in Documentation/dev-tools/kunit/.
2012-03-18 14:07:42 -04:00
config SUNRPC_DEBUG
bool "RPC: Enable dprintk debugging"
depends on SUNRPC && SYSCTL
2014-11-26 14:44:43 -05:00
select DEBUG_FS
2012-03-18 14:07:42 -04: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-18 19:45:47 -04:00
2015-06-04 11:21:42 -04:00
config SUNRPC_XPRT_RDMA
tristate "RPC-over-RDMA transport"
2018-05-25 23:29:59 +02:00
depends on SUNRPC && INFINIBAND && INFINIBAND_ADDR_TRANS
2014-03-18 19:45:47 -04:00
default SUNRPC && INFINIBAND
2017-04-09 13:06:16 -04:00
select SG_POOL
2014-03-18 19:45:47 -04:00
help
2015-06-04 11:21:42 -04:00
This option allows the NFS client and server to use RDMA
transports (InfiniBand, iWARP, or RoCE).
2014-03-18 19:45:47 -04:00
2015-06-04 11:21:42 -04:00
To compile this support as a module, choose M. The module
will be called rpcrdma.ko.
2014-03-18 19:45:47 -04:00
2015-06-04 11:21:42 -04:00
If unsure, or you know there is no RDMA capability on your
hardware platform, say N.
