From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 084B7C433FE for ; Thu, 6 Oct 2022 14:14:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 815848E0002; Thu, 6 Oct 2022 10:14:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C4458E0001; Thu, 6 Oct 2022 10:14:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68BEE8E0002; Thu, 6 Oct 2022 10:14:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 576BD8E0001 for ; Thu, 6 Oct 2022 10:14:16 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 25ECBA0FA5 for ; Thu, 6 Oct 2022 14:14:16 +0000 (UTC) X-FDA: 79990719312.05.52BF1AF Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by imf11.hostedemail.com (Postfix) with ESMTP id C854D4001A for ; Thu, 6 Oct 2022 14:14:14 +0000 (UTC) Received: by mail-io1-f43.google.com with SMTP id q200so946867iod.7 for ; Thu, 06 Oct 2022 07:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uPoSw2DcS8I2PL1GAxLCIjBZkmIbahmymE7q5ESqNH4=; b=J9UmphxOwRlKuKwKJGEStMq2njru+PiIwGVLUfPBPq5L+NiQWR0X0ph0BMc2W5nbt8 4fY0afnp5OGHoR48WDeXsZwHxoMN5k4f3cAvRzRwXhvGYbcMUIpKQGeu62j2J2SnGy+J Xj/w4pUH+FdGPKiKioCFBigar50r6VlCGptHXogYu0vEHZthEC9POAERgLfXsIlNUJAT 4LL5lhcH/9QJf5wjtvXr093IFQ5FVgHnW9DKsbH5n9oFVp8IFEYJH/pVve/xHlsOIZTb JrrThpZZTRv6pIFAUlojtCkCpeK6hrRAxbyXE8fkyWQe0FnS13WwHzjaGBDQmYXcBSxS r/Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uPoSw2DcS8I2PL1GAxLCIjBZkmIbahmymE7q5ESqNH4=; b=DlXprWrgUnrey/DnFMdfl59M3A8C7Mxssj3PQvX82tlMnB2NTksCHk18HOl8CdhBWg gCuMbP083ZWf2YVGgLQWsWhAY7326vIpiyORjQbxMzolwv2tBM/p2tX3HYaLR/cOAPX0 KkJ3rfO23tJTJq3gWrY32HFwjfo9Gi+5UWBV0+i0ACy9Verm6J4ii+GJH19Vs+80fgux WpA+wWihE1A4I2x1I8+cnqM9iDa61pgoMakrNzxL9A8AOft9m7NwViH1iZRlx1StYjCq 02vjzUgw9foVv9ii/b5tK8Bh4HJxsFPybtOOF3nZpGIJgZMp1rZUf4/YJucdQXfTla6K Iv5A== X-Gm-Message-State: ACrzQf1mjbjy7sCXSRdLwZfbm168K9pRj30UcqZB047zsf2lIE0VMaIn lbzXGNPw+nkkUd+yCyEJ+vz4jy8+ah8TNqDlBInzkg== X-Google-Smtp-Source: AMsMyM6kii+MO2rLiB+gLKVkRtdEKc2Fqc0GkifGVmj9R/yf+5vbD7WJTCsBBNNUYIzb2JEn4WLbsp9vBGxMSZlBt2Y= X-Received: by 2002:a6b:5d07:0:b0:6bb:7253:a439 with SMTP id r7-20020a6b5d07000000b006bb7253a439mr37286iob.2.1665065653849; Thu, 06 Oct 2022 07:14:13 -0700 (PDT) MIME-Version: 1.0 References: <20221006082735.1321612-1-keescook@chromium.org> <20221006082735.1321612-2-keescook@chromium.org> <20221006090506.paqjf537cox7lqrq@wittgenstein> In-Reply-To: <20221006090506.paqjf537cox7lqrq@wittgenstein> From: Jann Horn Date: Thu, 6 Oct 2022 16:13:37 +0200 Message-ID: Subject: Re: [PATCH 1/2] fs/exec: Explicitly unshare fs_struct on exec To: Christian Brauner Cc: Kees Cook , Eric Biederman , Jorge Merlino , Alexander Viro , Thomas Gleixner , Andy Lutomirski , Sebastian Andrzej Siewior , Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , Richard Haines , Casey Schaufler , Xin Long , "David S. Miller" , Todd Kjos , Ondrej Mosnacek , Prashanth Prahlad , Micah Morton , Fenghua Yu , Andrei Vagin , linux-kernel@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665065654; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uPoSw2DcS8I2PL1GAxLCIjBZkmIbahmymE7q5ESqNH4=; b=w27kS/vqTvYf8UAMAIOEPSXPEfuEpEcdcH9CwFRxffRwAS1ci5YTYGr3pq/Thxn3A/rDNQ HI0X+6V+s4LUpv0eA8LhRT59l+P2FtVmcZY+hjV4euuJyjKE5xUG6mKmTWWQuMstxJMzB+ BX03fU5yb4Z3HrdLwrg4xi2hFTWET1Q= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=J9UmphxO; spf=pass (imf11.hostedemail.com: domain of jannh@google.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665065654; a=rsa-sha256; cv=none; b=lI/2DBSrMbUlYZoxFyuixS8Fy8oayIk1rCxIlTupinIGFEHljFez+dNJ12PN1grTDHn/ao SGFqiOLPzgms66tYNB958dedSxDbFg05/QxDs/5pOfkYE/u+dmB89SSRd+l0j1lBEmfAAK qhedC/lKwb8GmqYWGu5CHDE5/6vZM2I= Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=J9UmphxO; spf=pass (imf11.hostedemail.com: domain of jannh@google.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: C854D4001A X-Rspam-User: X-Stat-Signature: iiakgrj45mdeh5shmijfaa96zyieme7w X-HE-Tag: 1665065654-469426 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 6, 2022 at 11:05 AM Christian Brauner wrote: > On Thu, Oct 06, 2022 at 01:27:34AM -0700, Kees Cook wrote: > > The check_unsafe_exec() counting of n_fs would not add up under a heavily > > threaded process trying to perform a suid exec, causing the suid portion > > to fail. This counting error appears to be unneeded, but to catch any > > possible conditions, explicitly unshare fs_struct on exec, if it ends up > > Isn't this a potential uapi break? Afaict, before this change a call to > clone{3}(CLONE_FS) followed by an exec in the child would have the > parent and child share fs information. So if the child e.g., changes the > working directory post exec it would also affect the parent. But after > this change here this would no longer be true. So a child changing a > workding directoro would not affect the parent anymore. IOW, an exec is > accompanied by an unshare(CLONE_FS). Might still be worth trying ofc but > it seems like a non-trivial uapi change but there might be few users > that do clone{3}(CLONE_FS) followed by an exec. I believe the following code in Chromium explicitly relies on this behavior, but I'm not sure whether this code is in active use anymore: https://source.chromium.org/chromium/chromium/src/+/main:sandbox/linux/suid/sandbox.c;l=101?q=CLONE_FS&sq=&ss=chromium