mirror of
https://sourceware.org/git/glibc.git
synced 2025-08-08 17:42:12 +03:00
elf: Ignore GLIBC_TUNABLES for setuid/setgid binaries
The tunable privilege levels were a retrofit to try and keep the malloc tunable environment variables' behavior unchanged across security boundaries. However, CVE-2023-4911 shows how tricky can be tunable parsing in a security-sensitive environment. Not only parsing, but the malloc tunable essentially changes some semantics on setuid/setgid processes. Although it is not a direct security issue, allowing users to change setuid/setgid semantics is not a good security practice, and requires extra code and analysis to check if each tunable is safe to use on all security boundaries. It also means that security opt-in features, like aarch64 MTE, would need to be explicit enabled by an administrator with a wrapper script or with a possible future system-wide tunable setting. Co-authored-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: DJ Delorie <dj@redhat.com>
This commit is contained in:
@@ -64,16 +64,6 @@ struct _tunable
|
||||
tunable_val_t val; /* The value. */
|
||||
bool initialized; /* Flag to indicate that the tunable is
|
||||
initialized. */
|
||||
tunable_seclevel_t security_level; /* Specify the security level for the
|
||||
tunable with respect to AT_SECURE
|
||||
programs. See description of
|
||||
tunable_seclevel_t to see a
|
||||
description of the values.
|
||||
|
||||
Note that even if the tunable is
|
||||
read, it may not get used by the
|
||||
target module if the value is
|
||||
considered unsafe. */
|
||||
/* Compatibility elements. */
|
||||
const char env_alias[TUNABLE_ALIAS_MAX]; /* The compatibility environment
|
||||
variable name. */
|
||||
|
Reference in New Issue
Block a user