From patchwork Tue Oct 10 18:01:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella X-Patchwork-Id: 77428 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CFF10385CC88 for ; Tue, 10 Oct 2023 18:01:35 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 16314385840F for ; Tue, 10 Oct 2023 18:01:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 16314385840F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1c60f1a2652so896475ad.0 for ; Tue, 10 Oct 2023 11:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696960877; x=1697565677; darn=sourceware.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=aY3wwtY+lhqt0DkFTsYAM/uZSQvzKWSK5epvy1/n/oU=; b=vMbRVY59443IV4OgO1FvRsMVvT38Km6hz8FEB9PoOAweD6HrrpPcvqq+2AQkYVEbFB U583XFvXnQrZpEzEzT8nbn+dEpAzlfmc3LRQszk8jyfG9wo7Pg8o4zeIjLqMHkt/qN9B khPWNPbHaxJSqEZ14m7Mrb12V8Ou2QAKEHHkMVSQbwt8+Zfy1i/vzEUU2CJMCjp/XB+C JXBBNNjg/6iSdnxvSocyhN5dRxtgPwbMJVjbYkKdnhEvZ9FrXpX4JkVWyolC6Id/pyPS fRgSpLM44Nuv2b2daKQhCdu4vEljNnQiIZBmWEqwKUNVmPMsC7twUCjUJabyRjizePWz A7mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696960877; x=1697565677; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aY3wwtY+lhqt0DkFTsYAM/uZSQvzKWSK5epvy1/n/oU=; b=cLSEupQnQFEuKT5//dmcbjBoo7Ep/5HbVWcBuxLeqh2uNBJAuiSlgIWcedQNOkHuSW dbcDjT6q+3Jvn5ftno+X63Q+05QLM2nZ3kUWnzgNkuatDnactgwKURlav6VRU5BVk2Nj nQOe4WoyoovPe084fXapGcOfLdw14UNKV7Xx1DxEruYR/yV7nS4gvUEmzA1Vg1sEN4wD incWC8jGFfJE/lnd4l6a5KbDJ60Jr1AoJQTzto9tNVnutRrYHVXZsKUOxR9p80jDW0jB KpRWl2OGNSWR8iDle8h5sqldKCUSNYAK0t5WxQH7cEYL0ClACgAbEruk2jNPFFIBtW5a hsnw== X-Gm-Message-State: AOJu0YwbncL67qC1kdSeYG/A+QbA4/YgnVkWHU3ZQ83344x5rSUuSD8U 1IyTDsZRpF4c+pE3WIyXEvsv5/4XaHkfy+8P5WB+tQ== X-Google-Smtp-Source: AGHT+IEAbj4hUkq3GmUnGblHJ7nxikKYMbkhpAz+equLQKVgv5pEHKH4nX/Cbufo7zepo24vT3DPLg== X-Received: by 2002:a17:902:c411:b0:1c3:e2eb:f79d with SMTP id k17-20020a170902c41100b001c3e2ebf79dmr25914797plk.8.1696960877486; Tue, 10 Oct 2023 11:01:17 -0700 (PDT) Received: from mandiga.. ([2804:1b3:a7c2:d09b:ef2e:7c42:5ecf:a4ef]) by smtp.gmail.com with ESMTPSA id 5-20020a170902c24500b001bb9d6b1baasm12088022plg.198.2023.10.10.11.01.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 11:01:16 -0700 (PDT) From: Adhemerval Zanella To: libc-alpha@sourceware.org, Siddhesh Poyarekar Subject: [PATCH 01/11] elf: Remove /etc/suid-debug support Date: Tue, 10 Oct 2023 15:01:01 -0300 Message-Id: <20231010180111.561793-2-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231010180111.561793-1-adhemerval.zanella@linaro.org> References: <20231010180111.561793-1-adhemerval.zanella@linaro.org> MIME-Version: 1.0 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org 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. --- elf/dl-tunables.c | 16 ---------------- elf/rtld.c | 3 --- manual/memory.texi | 4 +--- manual/tunables.texi | 4 +--- 4 files changed, 2 insertions(+), 25 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..318a3661f0 100644 --- a/elf/rtld.c +++ b/elf/rtld.c @@ -2670,9 +2670,6 @@ process_envvars (struct dl_main_state *state) } while (*nextp != '\0'); - if (__access ("/etc/suid-debug", F_OK) != 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 776fd93fd9..347b5698b5 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