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 68ACCC433FE for ; Thu, 6 Oct 2022 07:01:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABA476B0071; Thu, 6 Oct 2022 03:01:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6A8F6B0073; Thu, 6 Oct 2022 03:01:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 932116B0074; Thu, 6 Oct 2022 03:01:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7F87F6B0071 for ; Thu, 6 Oct 2022 03:01:34 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 49C3F120C5B for ; Thu, 6 Oct 2022 07:01:34 +0000 (UTC) X-FDA: 79989628908.17.FCD9456 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf05.hostedemail.com (Postfix) with ESMTP id BD25B100016 for ; Thu, 6 Oct 2022 07:01:33 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id x6so887998pll.11 for ; Thu, 06 Oct 2022 00:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=+lbQl0rCWp6tUyMuSCFzB+6AqJEUrQkOLadwCqKXhk8=; b=P95tTnDc1Zlo/FcKgRsnGgHRjJuXF/BFr+q4DuBF33xCmhNVRs6A28XD98ty9ydWhR I0fNfA9HigrTrxzxM8SRehh5Ge3szOsR8uqcuHDzpkuDwL28EF8Nx7W6Jtxnf4ewqv7c vZdNf5PJ4XLSjhccFK2aEjcik36/tWfKRJXjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=+lbQl0rCWp6tUyMuSCFzB+6AqJEUrQkOLadwCqKXhk8=; b=E6PcGC+ziyvYVk3mtqCFtbxGobSDzMBty486fwwTDawPvZrgLi0cFiWa75Jcj2fRCL MlZ241B8zjZ6OhoPdGqRw0gKc1d9qI1nwEhGlv43L5R89T2Rse6RrTBPSW/KJFG3xZjr 9+DkDAHIYV70/ZgEyzkId2KodO5JDuozLEjUT01K0RmVVTdPO8qbec2SFtNsNM1Oq0Yw NupVh0MicrXHkO4gYm/0py+1C34iAEycqacCGOnHW8bBTJUNtMJHdyPe7LIkkCGjWqep 9gCSQNs7wXRE+/wXGH5d0oRZjpEydeK5YXrnfeM7QmdXaWHYytXoA4MR6hEpWKh71/jS CYRA== X-Gm-Message-State: ACrzQf0Gd4b6GD3aOY7QVsbRiAvt0Yg7GTrWMV5zbxKbR5dGsC//4IRD tyCyLLP8gSQtabPSCyX2xq/h+w== X-Google-Smtp-Source: AMsMyM6P4p2fzjX7EoySe3pBKUHcQlET2UNqLJholUcyZnckHtT8XafYbihl5e+uuD/gwL/5Z3GhKA== X-Received: by 2002:a17:902:ed97:b0:17f:7ad0:16cb with SMTP id e23-20020a170902ed9700b0017f7ad016cbmr3342781plj.97.1665039692613; Thu, 06 Oct 2022 00:01:32 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id k12-20020a17090a62cc00b002008d0df002sm2173296pjs.50.2022.10.06.00.01.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Oct 2022 00:01:31 -0700 (PDT) Date: Thu, 6 Oct 2022 00:01:30 -0700 From: Kees Cook To: Jorge Merlino , David Howells , Eric Biederman , Alexander Viro , Hugh Dickins Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Fix race condition when exec'ing setuid files Message-ID: <202210052326.5CF2AF342@keescook> References: <20220910211215.140270-1-jorge.merlino@canonical.com> <202209131456.76A13BC5E4@keescook> <202210051950.CAF8CDBF@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202210051950.CAF8CDBF@keescook> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665039693; a=rsa-sha256; cv=none; b=fnoAJKuiD0kZeLNx6FxeudS6ACnoNw/qdUM5GL0BX7IVOOn5cBwznhP6bk6ft6hzTTd6Vc 2ErsJ9zWAqHJZCMkJYtjyfAIvQ7eG5npUH8j2Enm7n3e5GLk513QpcJlZMXH/WtQd6nhZ9 ECsCkubtmpSfHb7QenV3UfCdH9ALtQQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=P95tTnDc; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf05.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.175 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665039693; 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=+lbQl0rCWp6tUyMuSCFzB+6AqJEUrQkOLadwCqKXhk8=; b=XfPyPiLRkE1ZB+Y10nhY7s+zNRSugq234mWKOBpQFIa0Z65F8OpdcRIaZBaFUWGdbE0k/B mnWoL5Va61A65LdvbckhkxevMuzkoVF2mjRBOo+Fwvii9NvyDsJqXyPiRMjttfM/kpgqlK hGdELdMYB7cHttdpFuFblttYftV6P/4= X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=P95tTnDc; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf05.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.175 as permitted sender) smtp.mailfrom=keescook@chromium.org X-Stat-Signature: 4yju9n4gqkkq1rwozpdiz9cu9apuctdk X-Rspamd-Queue-Id: BD25B100016 X-Rspamd-Server: rspam09 X-HE-Tag: 1665039693-603330 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 Wed, Oct 05, 2022 at 08:06:15PM -0700, Kees Cook wrote: > Dave, this tracks back to commit a6f76f23d297 ("CRED: Make execve() take > advantage of copy-on-write credentials") ... any ideas what's happening > here? Er, rather, it originates before git history, but moved under lock in commit 0bf2f3aec547 ("CRED: Fix SUID exec regression"). Eric, Al, Hugh, does this ring a bell? It originates from 1da177e4c3f4 ("Linux-2.6.12-rc2") in git... static inline int unsafe_exec(struct task_struct *p) { int unsafe = 0; ... if (atomic_read(&p->fs->count) > 1 || atomic_read(&p->files->count) > 1 || atomic_read(&p->sighand->count) > 1) unsafe |= LSM_UNSAFE_SHARE; return unsafe; } Current code is: static void check_unsafe_exec(struct linux_binprm *bprm) { struct task_struct *p = current, *t; unsigned n_fs; ... t = p; n_fs = 1; spin_lock(&p->fs->lock); rcu_read_lock(); while_each_thread(p, t) { if (t->fs == p->fs) n_fs++; } rcu_read_unlock(); if (p->fs->users > n_fs) bprm->unsafe |= LSM_UNSAFE_SHARE; else p->fs->in_exec = 1; spin_unlock(&p->fs->lock); } Which seemed to take its form from: 0bf2f3aec547 ("CRED: Fix SUID exec regression") Quoting the rationale for the checks: ... moved the place in which the 'safeness' of a SUID/SGID exec was performed to before de_thread() was called. This means that LSM_UNSAFE_SHARE is now calculated incorrectly. This flag is set if any of the usage counts for fs_struct, files_struct and sighand_struct are greater than 1 at the time the determination is made. All of which are true for threads created by the pthread library. So, instead, we count up the number of threads (CLONE_THREAD) that are sharing our fs_struct (CLONE_FS), files_struct (CLONE_FILES) and sighand_structs (CLONE_SIGHAND/CLONE_THREAD) with us. These will be killed by de_thread() and so can be discounted by check_unsafe_exec(). So, I think this is verifying that when attempting a suid exec, there is no process out there with our fs_struct, file_struct, or sighand_struct that would survive the de_thread() and be able to muck with the suid's shared environment: if (atomic_read(&p->fs->count) > n_fs || atomic_read(&p->files->count) > n_files || atomic_read(&p->sighand->count) > n_sighand) Current code has eliminated the n_files and n_sighand tests: n_sighand was removed by commit f1191b50ec11 ("check_unsafe_exec() doesn't care about signal handlers sharing") n_files was removed by commit e426b64c412a ("fix setuid sometimes doesn't") The latter reads very much like the current bug report. :) So likely the n_fs test is buggy too... After de_thread(), I see the calls to unshare_sighand() and unshare_files(), so those check out. What's needed to make p->fs safe? Doing an unshare of it seems possible, since it exists half as a helper, unshare_fs(), and half open-coded in ksys_unshare (see "new_fw"). Should we wire this up after de_thread() like the other two? -Kees -- Kees Cook