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 9F42CC3ABC3 for ; Tue, 13 May 2025 13:06:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5A846B00D2; Tue, 13 May 2025 09:06:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE3B26B00D3; Tue, 13 May 2025 09:06:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C36696B00D4; Tue, 13 May 2025 09:06:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9F28E6B00D2 for ; Tue, 13 May 2025 09:06:06 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5C297140A43 for ; Tue, 13 May 2025 13:06:08 +0000 (UTC) X-FDA: 83437907616.28.13FB151 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf05.hostedemail.com (Postfix) with ESMTP id 9AA7510001D for ; Tue, 13 May 2025 13:06:06 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hcwMuekk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747141566; a=rsa-sha256; cv=none; b=QFlnu4ePlLFXhJm4yqB3rV+eVatlmQfwP3fFrI0tB00YmCgIPf16oWkiz/ELN0oB9N8UDT /oF/3vbcGKlYrB8z1RfA7Hpf3VBgnZ+VitjNwteGCiOExtSm83HCOZi8oTfPGJIYsF4jDc VmLkGCFFcDRDYR2UedGeoP3YNDkUTXE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hcwMuekk; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747141566; 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=ZRH4yaq02O4BeoAY/f143mbK8AEXX3uy5ZGAgLBp4KM=; b=mRGLXSXkGrFf1W7MSN6AZ5zMvwO3DbfOD0B9BUnGdw/TQS7wMIRVN/1BLu18E9hHWR674P CE2pBLm79bnv2fDy1X29H7I0PJ19bU80+iQS0ry6kEX9Kete74ChJLEajF90IotFNE6JVt BWsmDPWAp6rD2ZXVS54Ag/GE/QLO4DI= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-43edecbfb94so57819715e9.1 for ; Tue, 13 May 2025 06:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747141565; x=1747746365; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZRH4yaq02O4BeoAY/f143mbK8AEXX3uy5ZGAgLBp4KM=; b=hcwMuekkS3qvMTgGBstHjV6TEP6Q04CeJ5ymIkA0MHrt25a5ik8s0hqkrxtSEaDt+8 RyugFXtgTX+xSnd3Hvf0cAHssZHDOQrWdpnlObPeTuho16P6wWaN+RDW+2SfeLmXX+H8 wXTfby840iDF3ep992ZkpmcqlNvmeDJ1yROhKEVNkTBHGhr2dE7oA4G11uqoqPY/ylO7 YP0wflDVXoyzbehBBgzgjUwdKAZkaFj2UqACCU84wi8f9SQsuW8sbONNOcrTL9nCMAAC ZIIjzkPZswCpeJHrTjD3q2JbyZYyCigKSNQB2l6UZ9mav2eN00lCXxt/5WDCpMziglpc jevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747141565; x=1747746365; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZRH4yaq02O4BeoAY/f143mbK8AEXX3uy5ZGAgLBp4KM=; b=RpzXPGQdIFDsYadKMbO9lfMj3wlF+0MntasE2KQTU+frovmr/HEqe2ANZA6jYYUq/d FFnMWgtexik0uPiHID/k1O8ywFVxxY/Pk4Sqx3T0sZ3YQ2jeM7W1Yp4X0rwv+lJCdElm N3u2Utd8Pa/V5DpKdsHhkeYauHeA4V0KjGo6zShwwNFnXIBbz4lbs4qq38wdm/yQKt0g f8HPxupM5spCmzGAbwMzpXUkhO4qDaDoq2pJKVYxHpAWRVoCCqzBFtVnTaPTZByW3VR9 DMQ5sCWWbJJVclhqqCxnB+A8x/Nq58ulEZfjCXYoFZWZVvtYxSY6Rnpt8PnPZSH8f95m btHA== X-Forwarded-Encrypted: i=1; AJvYcCV7htBRopTxXpt+EVK8NwioawUKVO7OoLUIcx5mcXrEJypyc1qS4tKclhHoHzBsXy9PNMeNJhR9Lg==@kvack.org X-Gm-Message-State: AOJu0Yxj4cGN/wMP7MA+F4DQ8nT1kcjU91JDf9EeIxrNS5sA6yey9Wl1 f/KZjjeisH2xnzJnDseWI1ddmSh0KCEgkCxNlh0J0tFzjabVNY3v X-Gm-Gg: ASbGncub+B/cXzQG13muWGHYfZ6NCXR+gAMN5+83mm+HLGBePCyfMeHyI4ajXfiPt2y AV2dVM1ofbXOAvAz44SYn4Zs/SQJQ6zW8X/rS5mcl/OdHlcpsUDXFx5aU7mYld87ygk9dwc3eKe EJn4RfWcXXQGI8LunwGlggdfU+liUkW6StA0vy7GQAHPbXY4TvTNKKlXfFayhSM5Drt3SH3DdOx N6XddKMeF7j45TFS1brzdtmVPB2SZ5NZK/Zw5Ri9AmICD5oFrwUYpAxjQwT+XF/gXJnU59OKSs4 q6GonlE1O3Y0vUH6hTTqDlLfP+ZdJD4HAMTwW5AFb4j9FAPdcHkeBSj9ieAfPE1K X-Google-Smtp-Source: AGHT+IEHBhhE7TvsAD/FnNo4BJJ0fgMjXWx6eOMY8JlawqVvxffhuMX7kttizQAJ+g7X01ahmWKKUQ== X-Received: by 2002:a05:600c:3587:b0:43c:fdbe:43be with SMTP id 5b1f17b1804b1-442d6dd216fmr140842115e9.27.1747141561377; Tue, 13 May 2025 06:06:01 -0700 (PDT) Received: from f (cst-prg-88-99.cust.vodafone.cz. [46.135.88.99]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-442cd32f3c2sm209934765e9.15.2025.05.13.06.05.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 May 2025 06:06:00 -0700 (PDT) Date: Tue, 13 May 2025 15:05:45 +0200 From: Mateusz Guzik To: Kees Cook Cc: Jann Horn , Christian Brauner , 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, oleg@redhat.com Subject: Re: [PATCH 1/2] fs/exec: Explicitly unshare fs_struct on exec Message-ID: References: <20221006082735.1321612-1-keescook@chromium.org> <20221006082735.1321612-2-keescook@chromium.org> <20221006090506.paqjf537cox7lqrq@wittgenstein> <86CE201B-5632-4BB7-BCF6-7CB2C2895409@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <86CE201B-5632-4BB7-BCF6-7CB2C2895409@chromium.org> X-Stat-Signature: icokh9q7nqc357ri4knokw41yho8rh58 X-Rspam-User: X-Rspamd-Queue-Id: 9AA7510001D X-Rspamd-Server: rspam06 X-HE-Tag: 1747141566-999401 X-HE-Meta: U2FsdGVkX18f5jzOhdpqtwDbwHd9Vt7sk/zZT5p55UFcVoaxWNoeCWNJCsGeIFD8lsCa2ns0awow2xEEJWVnFcxeBhY+GHMfNLy3/gJwdcban52T1HlJzv7/d7PJ+eezn3JYtknDAvCYNKmsfRTBOmqyIayFK+vaDZi8KHXtV5tzEoOSmxSpBjs73PnEwfuz+ZPbPaSRkSqJfrI65+HpXnlT/hP/wnplqwErGHkw8CtN6QaFY+u85Z//nta9gVCxm3FYmD2SKB5h1HlKnmt90OPycxSfaIqSfEAnRs0TkYT1eA2Xv9++RCWnz8b7YbC9rQscsRIxEoFQPwjQGULqtasK8PAXpviuINN+KkLXT1qk68hvcF4dvgzKeEZo3SgdLRFm6iVJZOiNrvOslQWJfzuIJ083UlkH4H74MKnYbt1GNrfNgLsw/WK4f0L2NpmSRSDxY7cgkn7eMAjH2RpOn1yyXyj39soDBPfwLE+nWrxW/SN+u6KuzPSilqKlmpRgycFEbY1dGKdQUNtNzMmge/C+vAY5fwGIBrP/rnt1KaET+xLb0tNxLtgnwNunXsL3BAIRu//BPQujOd0y78ZKKHzebsMgYqlm3XpBppC+gUe5QdEDUFsAOPoEgkOZq83hHr3qguFMuGgqF9VbdoHrFZvMwvp/w5w3mNX+rWZaZ+dG68GhEZbuo3sK4uO+swlQLsRmkWAQ4sGYG+blMYQGiTC9Ipq8cZNl3PeAjOcuqegmlo8Yw2iKqCvDjKhW76k0U8IqwtPFIm2Pm6/8/DK4unJedN0D5zxmeh8pafRsxSjuzBPzmOr3m9YhCpT5FiYeHNCdUzzcd8y3N2x3HwYxMyaOLGiDS+z8Hsj2RPXIXXV3Q29j1aU/7cn9olu0iD4qbfEEzG3Zy489eVG8g2S2kAVYQ3Od7zRueom2RyfEl4xyfdSAa/aTiOF6frtND3vY9jYUxOYNC1cMG2SYeMb tbpWM1oc yHZ/h5E/+m2N7oj8zK08edGj4saTJxZvzN5uwN7tXdWcTbxegOQhTjF0TxCBiNm0jG4BQIozm0jtG0rJMJlqm5Kjwuv5cCVvX2gVVWEJWDUn3g5QZOoTWo6kSweR1/xpzUqn+ 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: List-Subscribe: List-Unsubscribe: On Thu, Oct 06, 2022 at 08:25:01AM -0700, Kees Cook wrote: > On October 6, 2022 7:13:37 AM PDT, Jann Horn wrote: > >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 > > Oh yes. I think I had tried to forget this existed. Ugh. Okay, so back to the drawing board, I guess. The counting will need to be fixed... > > It's possible we can move the counting after dethread -- it seems the early count was just to avoid setting flags after the point of no return, but it's not an error condition... > I landed here from git blame. I was looking at sanitizing shared fs vs suid handling, but the entire ordeal is so convoluted I'm confident the best way forward is to whack the problem to begin with. Per the above link, the notion of a shared fs struct across different processes is depended on so merely unsharing is a no-go. However, the shared state is only a problem for suid/sgid. Here is my proposal: *deny* exec of suid/sgid binaries if fs_struct is shared. This will have to be checked for after the execing proc becomes single-threaded ofc. While technically speaking this does introduce a change in behavior, there is precedent for doing it and seeing if anyone yells. With this in place there is no point maintainig ->in_exec or checking the flag. There is the known example of depending on shared fs_struct across exec. Hopefully there is no example of depending on execing a suid/sgid binary in such a setting -- it would be quite a weird setup given that for security reasons the perms must not be changed. The upshot of this method is that any breakage will be immediately visible in the form of a failed exec. Another route would be to do the mandatory unshare but only for suid/sgid, except that would have a hidden failure (if you will). Comments?