aboutsummaryrefslogtreecommitdiff
path: root/manual/getopt.texi
diff options
context:
space:
mode:
authorAdhemerval Zanella <adhemerval.zanella@linaro.org>2023-11-06 17:25:36 -0300
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>2023-11-21 16:15:42 -0300
commit9c96c87d60eafa4d78406e606e92b42bd4b570ad (patch)
treef2b1db62e65cdf8cae4e058bea8e40aae847dc16 /manual/getopt.texi
parenta72a4eb10b2d9aef7a53f9d2facf166a685d85fb (diff)
downloadglibc-9c96c87d60eafa4d78406e606e92b42bd4b570ad.zip
glibc-9c96c87d60eafa4d78406e606e92b42bd4b570ad.tar.gz
glibc-9c96c87d60eafa4d78406e606e92b42bd4b570ad.tar.bz2
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>
Diffstat (limited to 'manual/getopt.texi')
0 files changed, 0 insertions, 0 deletions