public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Adhemerval Zanella <azanella@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc] elf: Remove /etc/suid-debug support
Date: Tue, 21 Nov 2023 20:48:31 +0000 (GMT)	[thread overview]
Message-ID: <20231121204831.4131C3858D33@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6c6fce572fb8f583f14d898e54fd7d25ae91cf56

commit 6c6fce572fb8f583f14d898e54fd7d25ae91cf56
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Mon Nov 6 17:25:34 2023 -0300

    elf: Remove /etc/suid-debug support
    
    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>

Diff:
---
 elf/dl-tunables.c    | 16 ----------------
 elf/rtld.c           |  3 +--
 manual/memory.texi   |  4 +---
 manual/tunables.texi |  4 +---
 4 files changed, 3 insertions(+), 24 deletions(-)

diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c
index cae67efa0a..24252af22c 100644
--- a/elf/dl-tunables.c
+++ b/elf/dl-tunables.c
@@ -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)
     {
diff --git a/elf/rtld.c b/elf/rtld.c
index 5107d16fe3..51b6d9f326 100644
--- a/elf/rtld.c
+++ b/elf/rtld.c
@@ -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);
diff --git a/manual/memory.texi b/manual/memory.texi
index 5781a64f35..258fdbd3a0 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -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
diff --git a/manual/tunables.texi b/manual/tunables.texi
index 5549f70795..b31f16da84 100644
--- a/manual/tunables.texi
+++ b/manual/tunables.texi
@@ -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

                 reply	other threads:[~2023-11-21 20:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231121204831.4131C3858D33@sourceware.org \
    --to=azanella@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).