From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by sourceware.org (Postfix) with ESMTPS id 5A0DA3858426; Fri, 6 Oct 2023 12:26:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A0DA3858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 816E35C0227; Fri, 6 Oct 2023 08:26:03 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Fri, 06 Oct 2023 08:26:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1696595163; x=1696681563; bh=4C 13FxYpAHHiAG7PXbnL85UfjuHy/a5jVKGXb2a6BXQ=; b=clLaoUSHTz3bP+db/M ilMAAzWYDx/aOwamvJtW2fNo/r0Z9SwTirezOkB94ygHtwpfDnLZCGMt9r3i/vFH tT2+8e4g3U9ka0/xBaComPwcmwqFuOPhVLU/p7+xYtylOXrcbUoIFGDi+536wl5N qk7knqo8Fp21jNfNog4Ua1mjKyyPyuvJMtWF+PQQ247TqK4Z55JvrpzUaQx84Y6P Pu4gfGEPuqiqunp0AH+N7xI90OH6K8qRdjOkHNefHfxIW1/evz9xIFScZ0o6gEbs gRArmtDTXg/+2FcqtaEZ2RrTy6u9O14d4dSBifRV6EFuEXLsuG1QhEF4kN4xYyw8 NjBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1696595163; x=1696681563; bh=4C13FxYpAHHiA G7PXbnL85UfjuHy/a5jVKGXb2a6BXQ=; b=P43RS3aXCHqpojOFTmU3uMoufqrCM VvekLY3CmBw3LsuGjtJfgECFQSQ6VIcxQt7MD1IUIbI17wfQvWgR9M5E3An+3anc fjX6GjsZq4TZwppyA/2xL+2sr1NO34H0zMI6tRQMkKW1t9od1YyQAnBamIPa5/Im SyF6EC72trILVcIKswOyICHbB4pomhEPkXEbCQht0LyNXUHK+hYcTYUKKs89T4ve c65jQbdfhUlCRzR+jgowqltiktKKdwJCiIxdnKoiNZAhMMM0CwE5pxk7EH0K6qhC Sz1VfEl5siAKICtjmdqS9fPL5HhwRr9qff42sY/zMwgRa+rbHQLL3QrvA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrgeeigdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdgkrggt khcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtf frrghtthgvrhhnpefhleefheduhfelgeehgeejveehueeihedvgfeuueetteelieeiteeh fefhleduieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 33980272007B; Fri, 6 Oct 2023 08:26:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d MIME-Version: 1.0 Message-Id: In-Reply-To: References: <1d301638-abaa-4f0b-89a5-7fa75250bf5d@app.fastmail.com> Date: Fri, 06 Oct 2023 08:25:42 -0400 From: "Zack Weinberg" To: "Siddhesh Poyarekar" , "Szabolcs Nagy" , "Adhemerval Zanella" , "GNU libc development" Cc: "Florian Weimer" , "Carlos O'Donell" Subject: Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE Content-Type: text/plain X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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 Thu, Oct 5, 2023, at 3:11 PM, Siddhesh Poyarekar wrote: > On 2023-10-05 14:31, Zack Weinberg wrote: >> On Thu, Oct 5, 2023, at 9:59 AM, Szabolcs Nagy wrote: >>> i think it is broken to rewrite env[] that is passed by the >>> kernel. but since glibc always did this i guess it's fine. >> >> I think the CVE that prompted this discussion demonstrates that >> it's *insecure* to allow children of setxid processes to inherit >> any environment variable that is considered insecure to consult in >> the setxid process itself. > > 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. > The issue there is limited to complex parsing of a particular > environment variable in a setxid context and the main lesson there > IMO is to keep any kind of processing to a bare minimum in a setxid > context. Agreed. > Processing for environment inheritance (specifically, cleaning out > unsecvars) is fairly stable code that has stood the test of time. > It makes sense like you suggest below, to make it an inclusion list > rather than an exclusion list, but IMO that's a separate hardening > exercise from ripping tunables out of the setxid context. Also agreed. zw