Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp878193ybh; Wed, 11 Mar 2020 12:39:11 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuMqMLakvvPVbfJxhH7A/X4u26vrrBnQh9Kc8wrgC0ku89kkdZld5uoQEUybKU00FD937Or X-Received: by 2002:aca:ab16:: with SMTP id u22mr181771oie.133.1583955551041; Wed, 11 Mar 2020 12:39:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1583955550; cv=pass; d=google.com; s=arc-20160816; b=g9Nt5U7JCZKfU0+IeeQyw7HqtlJ/SDK34ieU2jgA9FQgPCcT2EogEm2/6voKUfmJoE R7+G1xfzMv+oOqdoaw/rMLKxP7YvihKPaowHSbLIe9hPDg8DhFSOn+4rZXGYGtXG7HwJ GdWObD0pgP6gLE0MG1MS0+DwEpaVODl5TdBtwoIlkbskKGmPrQ0mkzGxjmsSR+IWm4x5 F08uePzLyvBMta7/RRQjxtbF09g64gBf7vT1Ci+zA1s38oY3jtEvRzOd/OWwprQtIvkQ oMFiCh3GcA+4Rigiutwzg9KDN3OnYWNLepPRwfPBjtGqEwTncMNakdTk1U6PP/K/xxb+ HbJA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:in-reply-to:user-agent:date:message-id:from :references:cc:to:subject; bh=2nx7o+DSt7gNZ1iatttl7B9FP5QzBo0eRm3uNP7bG0E=; b=IuE8x8umIlHBA5NzbvJNsITzLwwbASjsFwvMb53bBDW4RMHMj930p822rDDVfiUEFU bE9VCSd0/UUBJnh7EAxeMRei47VXOtNsW5LylAEjnFnODwM9mKCvClCIIyrhncQG6Bt/ 2fPextNQjxYnD1FD6pb1tWXCy8RfvSoxiLHEEeRpKTgnacTsiymdXmqFtE/ek5Py9Ocv DklQMn1p+P+ipJK/F33FJ1NGZtmdJVcTYVW+8kGsg3Kek3yiYOXGPDix+oZREn82IRwj EUZL1x+rPBowWdn3Ox7HH74qyf3qTsMoiWJP+NggWeCC+sj/PfC1cMnuYjhhQOMHw4Mr e/2Q== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=hotmail.de dkim=pass dkdomain=hotmail.de dmarc=pass fromdomain=hotmail.de); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f9si1681167oti.44.2020.03.11.12.38.58; Wed, 11 Mar 2020 12:39:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=hotmail.de dkim=pass dkdomain=hotmail.de dmarc=pass fromdomain=hotmail.de); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731119AbgCKTim (ORCPT + 99 others); Wed, 11 Mar 2020 15:38:42 -0400 Received: from mail-oln040092074027.outbound.protection.outlook.com ([40.92.74.27]:64694 "EHLO EUR04-DB3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730913AbgCKTil (ORCPT ); Wed, 11 Mar 2020 15:38:41 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FxqizhXowGPVQb7gyJLcQECU/FqGhfzGmQd1MewWia2Rm4433r3CHJAgdJ/x8P52wZNKoDFaJzfvjbrcSKunKyxlQNV5Z0ycDmdwjdlHEVwMdaz1vDNEjOjJizINvoQAHg11chLO2OX4a7LdM9N5KCDe51IDl5SUkc3WT1eWRvDTWNXVxB3PIqObObuu60XsS4M7coyYr/9s7Hm5FdNCPNrpUnUc7IynwByLclkIMTzZkyunnGvLe2mOfxdX1pqElQxtTCFtyB2edKSXD7NYHCJuQrYj6UeFXWjnLakDgdKw/t5/rdbNWuOv2ToDONH8vVwU3hW1GS0nY9Scwy3LxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2nx7o+DSt7gNZ1iatttl7B9FP5QzBo0eRm3uNP7bG0E=; b=IuQPrn8WZwdVbjJAdoDhhAQaab+yyRCpg5J/efjDp2ppirKGrPiaRnhiBYMxwXvg8Nk1EaGm+Qo7HQnX38zrpd8G/UR5y4QBv4540hyZY2zVpcuxrz6oXReevd4DcnGpnLdJWQJk1GoevRD7pdk8ippkvJGAIvoGo3ULOjMkC6Pu+Mt2HlHu2LNOKuEsbChcfvPxn+e62tfKZ2+5p7mD5tGfuq/AwnM3NZVqh9xnQ9Z8i3TOTYmGQp/dC1oXJbF8S5K2WgOyzrOhKcgsxEQ0J8HDM+2pFeZtCVOUkB5KD6LuK5rirYB+8r02aSY1qSPZ+UUqNChc6vFoWpPqXh/WQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hotmail.de; dmarc=pass action=none header.from=hotmail.de; dkim=pass header.d=hotmail.de; arc=none Received: from DB3EUR04FT031.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::36) by DB3EUR04HT004.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0c::445) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Wed, 11 Mar 2020 19:38:38 +0000 Received: from PR2PR03MB5179.eurprd03.prod.outlook.com (10.152.24.54) by DB3EUR04FT031.mail.protection.outlook.com (10.152.24.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Wed, 11 Mar 2020 19:38:38 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:366CCCF2C02D71A0751CB0FC9F5A248A87BFE6D9F1FB3B1F06D9EAAB83B13DF6;UpperCasedChecksum:CA563FFDA8E05A80BB7B26D6AD28A01FB23FE5E84E8A0F30CDEE3775B2D8A5CF;SizeAsReceived:9923;Count:50 Received: from PR2PR03MB5179.eurprd03.prod.outlook.com ([fe80::5914:cd4e:9863:88c2]) by PR2PR03MB5179.eurprd03.prod.outlook.com ([fe80::5914:cd4e:9863:88c2%5]) with mapi id 15.20.2793.013; Wed, 11 Mar 2020 19:38:38 +0000 Subject: Re: [PATCH 2/4] proc: Use new infrastructure to fix deadlocks in execve To: Kees Cook Cc: "Eric W. Biederman" , Christian Brauner , Jann Horn , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "stable@vger.kernel.org" , "linux-api@vger.kernel.org" References: <87r1y12yc7.fsf@x220.int.ebiederm.org> <87k13t2xpd.fsf@x220.int.ebiederm.org> <87d09l2x5n.fsf@x220.int.ebiederm.org> <871rq12vxu.fsf@x220.int.ebiederm.org> <877dzt1fnf.fsf@x220.int.ebiederm.org> <875zfcxlwy.fsf@x220.int.ebiederm.org> <202003111208.640025F75@keescook> From: Bernd Edlinger Message-ID: Date: Wed, 11 Mar 2020 20:38:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: <202003111208.640025F75@keescook> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM3PR07CA0107.eurprd07.prod.outlook.com (2603:10a6:207:7::17) To PR2PR03MB5179.eurprd03.prod.outlook.com (2603:10a6:101:25::12) X-Microsoft-Original-Message-ID: <12e38caf-cd81-15bb-0f6e-c53ed2cabdae@hotmail.de> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.101] (92.77.140.102) by AM3PR07CA0107.eurprd07.prod.outlook.com (2603:10a6:207:7::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.9 via Frontend Transport; Wed, 11 Mar 2020 19:38:34 +0000 X-Microsoft-Original-Message-ID: <12e38caf-cd81-15bb-0f6e-c53ed2cabdae@hotmail.de> X-TMN: [AYF23+fkc86AnRk6FHpxGeBnU4JhYZ5N] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 50 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 860b4db5-a7f4-4cad-bbaf-08d7c5f3cabc X-MS-TrafficTypeDiagnostic: DB3EUR04HT004: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oeW4fZgyDIkVqd6f3sDWM700pD4I3P9Z6mDYV67IIuiFhwILMBd5Ky5MOJCweljF6Lf4ZyVMhGJoaFhZAJJnsh0v2rApaGZL1m1eIvspu8r7rfxNJdaT6HH9JFL5BzPRxZS3FiMLrl1SlTds6vb0juhskeH4vIFUvcIxVnxQ+RXngM5UmhpuXfF63FhFb3YH X-MS-Exchange-AntiSpam-MessageData: w9Wy/jGhlm+2KTCL8XOZJu/40LPAvvmmKkvHfIh0bKiLndqYEGoFVH8QfbcP9FQ11qLWrUyckUlranK24dHQ8xkfiFPwNwuMXIV5yA59Ngbm2oB7EVvFbd37ZRhGuwXZ1MDmLEwn+Az2BXthI5uy8A== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 860b4db5-a7f4-4cad-bbaf-08d7c5f3cabc X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2020 19:38:38.0437 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3EUR04HT004 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/11/20 8:10 PM, Kees Cook wrote: > On Tue, Mar 10, 2020 at 06:45:32PM +0100, Bernd Edlinger wrote: >> This changes lock_trace to use the new exec_update_mutex >> instead of cred_guard_mutex. >> >> This fixes possible deadlocks when the trace is accessing >> /proc/$pid/stack for instance. >> >> This should be safe, as the credentials are only used for reading, >> and task->mm is updated on execve under the new exec_update_mutex. >> >> Signed-off-by: Bernd Edlinger > > I have the same question here as in 3/4. I should probably rescind my > Reviewed-by until I'm convinced about the security-safety of this -- why > is this not a race against cred changes? > The credentials of a thread that is currently executing execve is already set in the bprm structure, however the credential in the task structure is not yet changed, as well as the process memory map keeps stable until the exec_update_mutex is acquired. What is done with this functions is access the call stack of the process before the new executable is actually started. There would immediately be a severe security problem if we did not use any mutex as the check would be then with the old credential, but the stack trace would potentially reveal secret function calls that are done by a setuid program when it starts up. Bernd. > -Kees > >> --- >> fs/proc/base.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/fs/proc/base.c b/fs/proc/base.c >> index ebea950..4fdfe4f 100644 >> --- a/fs/proc/base.c >> +++ b/fs/proc/base.c >> @@ -403,11 +403,11 @@ static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns, >> >> static int lock_trace(struct task_struct *task) >> { >> - int err = mutex_lock_killable(&task->signal->cred_guard_mutex); >> + int err = mutex_lock_killable(&task->signal->exec_update_mutex); >> if (err) >> return err; >> if (!ptrace_may_access(task, PTRACE_MODE_ATTACH_FSCREDS)) { >> - mutex_unlock(&task->signal->cred_guard_mutex); >> + mutex_unlock(&task->signal->exec_update_mutex); >> return -EPERM; >> } >> return 0; >> @@ -415,7 +415,7 @@ static int lock_trace(struct task_struct *task) >> >> static void unlock_trace(struct task_struct *task) >> { >> - mutex_unlock(&task->signal->cred_guard_mutex); >> + mutex_unlock(&task->signal->exec_update_mutex); >> } >> >> #ifdef CONFIG_STACKTRACE >> -- >> 1.9.1 >