AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-11-21 12:30:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

elf: Remove /etc/suid-debug support

Browse Source 
Since malloc debug support moved to a different library
(libc_malloc_debug.so), the glibc.malloc.check requires preloading the
debug library to enable it.  It means that suid-debug support has not
been working since 2.34.

To restore its support, it would require to add additional information
and parsing to where to find libc_malloc_debug.so.

It is one thing less that might change AT_SECURE binaries' behavior
due to environment configurations.

Checked on x86_64-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This commit is contained in:
Adhemerval Zanella 2023-11-06 17:25:34 -03:00
parent 64e4acf24d
commit 6c6fce572f
4 changed files with 3 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
elf/dl-tunables.c
View File

@ -252,20 +252,6 @@ parse_tunables (char *tunestr, char *valstring)
tunestr[off] = '\0';
}
/* Enable the glibc.malloc.check tunable in SETUID/SETGID programs only when
the system administrator has created the /etc/suid-debug file. This is a
special case where we want to conditionally enable/disable a tunable even
for setuid binaries. We use the special version of access() to avoid
setting ERRNO, which is a TLS variable since TLS has not yet been set
up. */
static __always_inline void
maybe_enable_malloc_check (void)
{
tunable_id_t id = TUNABLE_ENUM_NAME (glibc, malloc, check);
if (__libc_enable_secure && __access_noerrno ("/etc/suid-debug", F_OK) == 0)
tunable_list[id].security_level = TUNABLE_SECLEVEL_NONE;
}
/* Initialize the tunables list from the environment. For now we only use the
ENV_ALIAS to find values. Later we will also use the tunable names to find
values. */
@ -277,8 +263,6 @@ __tunables_init (char **envp)
size_t len = 0;
char **prev_envp = envp;
maybe_enable_malloc_check ();
while ((envp = get_next_env (envp, &envname, &len, &envval,
&prev_envp)) != NULL)
{

3
elf/rtld.c
View File

@ -2670,8 +2670,7 @@ process_envvars (struct dl_main_state *state)
}
while (*nextp != '\0');
if (__access ("/etc/suid-debug", F_OK) != 0)
GLRO(dl_debug_mask) = 0;
GLRO(dl_debug_mask) = 0;
if (state->mode != rtld_mode_normal)
_exit (5);

4
manual/memory.texi
View File

@ -1379,9 +1379,7 @@ There is one problem with @code{MALLOC_CHECK_}: in SUID or SGID binaries
it could possibly be exploited since diverging from the normal programs
behavior it now writes something to the standard error descriptor.
Therefore the use of @code{MALLOC_CHECK_} is disabled by default for
SUID and SGID binaries. It can be enabled again by the system
administrator by adding a file @file{/etc/suid-debug} (the content is
not important it could be empty).
SUID and SGID binaries.
So, what's the difference between using @code{MALLOC_CHECK_} and linking
with @samp{-lmcheck}? @code{MALLOC_CHECK_} is orthogonal with respect to

4
manual/tunables.texi
View File

@ -136,9 +136,7 @@ termination of the process.
Like @env{MALLOC_CHECK_}, @code{glibc.malloc.check} has a problem in that it
diverges from normal program behavior by writing to @code{stderr}, which could
by exploited in SUID and SGID binaries. Therefore, @code{glibc.malloc.check}
is disabled by default for SUID and SGID binaries. This can be enabled again
by the system administrator by adding a file @file{/etc/suid-debug}; the
content of the file could be anything or even empty.
is disabled by default for SUID and SGID binaries.
@end deftp
@deftp Tunable glibc.malloc.top_pad