From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 93F423858426 for ; Fri, 6 Oct 2023 17:10:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 93F423858426 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-pf1-x431.google.com with SMTP id d2e1a72fcca58-690d8c05784so2021244b3a.2 for ; Fri, 06 Oct 2023 10:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696612218; x=1697217018; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=5PekGYBavCRZYBZlsG32m9llOz2rH9Vt9hDFK4eNdQ8=; b=CEt6HhOJD9VEcxmZaUPjDVqVo8l9Sxweu3A4euJMtKRwuideyTAhn44loAVG8jkUPt sEEWaOiMsPgWCHsLXBSFoPyJq6FxLCvG2rS1wsETkHIaikXNF+N745uYAb/83RKqPFmm CZTOrNm2xm8VknYVJvxg6W8m3tUaZktK5iiiAYY1upVyN3GErPV9wGkNGes8204NNFJF 4fHKvzVQvqg0c6NAJlL9TEuGApbHwHX5pXj5RefOjx2dtrZf9uD09+sk5uIJLepFXROA /6d72eezoWh3BboQQ06utb1VqfVw/J/Yx/xzRSUDkRkztGLOG8p1IGX7XVrbOGyyjqI2 UTgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696612218; x=1697217018; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5PekGYBavCRZYBZlsG32m9llOz2rH9Vt9hDFK4eNdQ8=; b=woMW41tEeKnmcs2FxC3WxcQTDCHdCtznGhDMN3wInfZkBytUhSdi1S23reUvQR2eJw aTELk8kCBydUGAA8A0Lmz551UWjp2JC0s4sSP504urBLQo6weWROb8sgJ1DmAFKR6+1C nnxX4I7nRNYdlK2IrXLRJj2ZyMq3WUkEXd4QNWXM/UJ/8shFxZDiY4U+Z5wpGXK6qlTr nUkTk86USyNnwc2tRHoAhXyEx7F3fsvrVu4k/JXl6ql/qH9LSEzS/42YJQCiO68g2ppo eX7MqygVxM8t0x+LiRZQUB/AFBPakuIMm2nms+YQ0wD3fLzrtkOtLRK/WfGcHpaVp4fP NzNQ== X-Gm-Message-State: AOJu0YynffB+eL9dShl7aHXpLn57yqRLQEqXuUkLmpz6LAQBS7mXjrZd YBxMoyP5InERrBTock7fRgFwVQ== X-Google-Smtp-Source: AGHT+IEAgip3S37s/EXud5ow8oeuHe1X5z3JiejeMmsZLB1AAgLcPuosjHBpzHZ+MJMjccoMMKy+pQ== X-Received: by 2002:a05:6a00:398b:b0:690:c306:151a with SMTP id fi11-20020a056a00398b00b00690c306151amr9327779pfb.0.1696612217918; Fri, 06 Oct 2023 10:10:17 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:9e9:3fff:94f8:9e64? ([2804:1b3:a7c1:feaf:9e9:3fff:94f8:9e64]) by smtp.gmail.com with ESMTPSA id i13-20020a63bf4d000000b0057c449977efsm3188766pgo.39.2023.10.06.10.10.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Oct 2023 10:10:17 -0700 (PDT) Message-ID: <6659d8d5-7b0a-4a6f-82c5-f52a99ca2891@linaro.org> Date: Fri, 6 Oct 2023 14:10:14 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE Content-Language: en-US To: Siddhesh Poyarekar , Zack Weinberg , Szabolcs Nagy , GNU libc development Cc: Florian Weimer , Carlos O'Donell References: <1d301638-abaa-4f0b-89a5-7fa75250bf5d@app.fastmail.com> <4eaea4b7-c72f-8bd8-ab2b-dc08fc4ad97d@sourceware.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <4eaea4b7-c72f-8bd8-ab2b-dc08fc4ad97d@sourceware.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 06/10/23 09:41, Siddhesh Poyarekar wrote: > On 2023-10-06 08:25, Zack Weinberg wrote: >>> I don't completely disagree with the conclusion below, but the CVE >>> that prompted this discussion doesn't say anything about environment >>> inheritance because the vulnerability had nothing to do with >>> environment processing and inheritance. >> >> I may have misunderstood the CVE or mixed it up with another one. >> I thought there was a recent CVE in which a SXID_IGNORE environment >> variable was inherited by a child process, and that child process was >> rendered vulnerable to further exploitation because it honored that >> variable. > > Hmm, I don't remember anything like this recently (but my memory is worse than my airplane flying skills), but something like that would be an interesting data point and further confirmation that we need to get rid of SXID_IGNORE and SXID_NONE.  In any case, I can't see a good reason anymore to keep these levels, especially if we drop memory tagging, malloc tuning and malloc debugging tunables from SXID_IGNORE. If memory tagging needs to persist across setxid programs then there needs to be a different way, maybe through systemwide tunables[1] that DJ is working on, or maybe even ELF markup. > > Adhemerval has taken this patchset and is going to build on it to rip it all out, so we'll hopefully resolve all of this together. I think the less contiguous change would to keep with the blacklist of environment variables, since changing to whitelist will change the current semantic (and add possible user-visible breakage), ignore any tunable on AT_SECURE binaries (as some Linux distributions are already doing [1]), add GLIBC_TUNABLES to unsecvars (so if AT_SECURE binaries want to set any tunable, they should it explicit), and remove the requirement of duplice the GLIBC_TUNABLES tunable parsing (which some memory allocation failure). Yes, security hardening tunables won't be applied for AT_SECURE binaries, but I think opt-in security features that have performance implications should done by system administrator instead of relying on users. [1] https://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=commitdiff;h=5d1686416ab766f3dd0780ab730650c4c0f76ca9