From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by sourceware.org (Postfix) with ESMTPS id A48543858C35; Thu, 5 Oct 2023 18:32:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A48543858C35 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.west.internal (Postfix) with ESMTP id 34C223200A2E; Thu, 5 Oct 2023 14:32:02 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute5.internal (MEProxy); Thu, 05 Oct 2023 14:32:02 -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=1696530721; x=1696617121; bh=v5 PiLWHjT89tbA75FrhLbWRwcNLMaHlzqM+Ia9XTJgY=; b=Y1HPVR97w4sne64Evo aUDjdHD1oZ/XJImpgWeRNOuVReABL+pQ7T31w+sn8Q5/XRD/wyGF9252K5KO8TS6 vlt23x+idUoDN0txl0jCsKJxqSOKixP5bXGwvXlljlGfzesIftOextK4YJjNdLTw M+z1O2Jmys9W1E1Hy7hhbiW48ohRKz6l4xNcOhvVT6ed0mO6vBrdPqGS4YOkY6gD Iyed5v/cWhLQlrOV8Amd3N+xn5JrAYg+hON+N7Soc5c6Q0DrKa2XElIbQCaExWCH hTfAB0qkONw8vaieiHm2ArQlU9IZHg4BLOrMgGqkP6MqNF8T1RKt2bYSGPUTCxP+ fGRA== 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=1696530721; x=1696617121; bh=v5PiLWHjT89tb A75FrhLbWRwcNLMaHlzqM+Ia9XTJgY=; b=aqow7PAXs2pZhQg3j/GP9zHqOwimA l67QxnY0BltEePUooniglAVftdyBizVbqcwINugITRItY+dlh+P+nb4/36dSczfm wPFxIcd5Tn9/KqqhP+DZgEH/yQkgc3xzBZESHINfV70KjueNVo/LcjjzEHHS8REa F2ICjthPS3M4cAFwWsCQVBIuNIme2nF3PcEu1IFTf8ZUsJZOW3XamRJCDdETpHrT moNJ3SHXm1TW/O6bftw1T3X0YrW7FZx3aCtvZ79gvmRGMkYIQ2+CrlfImUJDeUze DI9UNBs+7ILLBchhc4+1aDjpK7w7y6VDbuECjJPBWDy90RC+WNfmlhKcg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrgeeggdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfelfeehudfhleegheegjeevheeuieehvdfgueeuteetleeiieet heefhfeludeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5FA3A272007B; Thu, 5 Oct 2023 14:32:01 -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: <1d301638-abaa-4f0b-89a5-7fa75250bf5d@app.fastmail.com> In-Reply-To: References: Date: Thu, 05 Oct 2023 14:31:40 -0400 From: "Zack Weinberg" To: "Szabolcs Nagy" , "Siddhesh Poyarekar" , "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,SPF_HELO_PASS,SPF_PASS,TXREP,URIBL_BLOCKED autolearn=no 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 9:59 AM, Szabolcs Nagy wrote: > The 10/05/2023 08:55, Siddhesh Poyarekar wrote: >> The current unsetenv logic is well reasoned IMO; the tunables layer made it >> complicated and it ought to be sufficient to just remove that. But that >> would require dropping the memory tagging tunable from SXID_IGNORE and >> erasing GLIBC_TUNABLES by putting it in unsecvars.h. > > 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 also think we ought to be talking about a very short *whitelist* of environment variables that are allowed to survive execve() of a setxid binary -- off the top of my head, TERM, LANG, LANGUAGE, LC_*, and maybe *nothing else* -- and putting that list into the kernel itself. zw