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 B5A01C3DA4A for ; Thu, 1 Aug 2024 15:15:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00E5A6B0099; Thu, 1 Aug 2024 11:15:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F009F6B009A; Thu, 1 Aug 2024 11:15:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC8CB6B009B; Thu, 1 Aug 2024 11:15:22 -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 BE3CE6B0099 for ; Thu, 1 Aug 2024 11:15:22 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 54044C0EF3 for ; Thu, 1 Aug 2024 15:15:22 +0000 (UTC) X-FDA: 82404025284.22.122549E Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf16.hostedemail.com (Postfix) with ESMTP id 1424A180026 for ; Thu, 1 Aug 2024 15:15:18 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="dooos/xL"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722525272; a=rsa-sha256; cv=none; b=xg5rHEdc9sJihNq5wIwtgt1pSLGGT234v+Q8Z0mSLjBr77zUjJVg+li9t51shhmukhBljo QOu1ZPxGsVdStdBtaEJXZyHgjVln2T/w2arIKxQHbuZWFDVmK5nOkFtPkODJCxffz31AgU 7uwypg20U1hFQUZEYQoI2jZ3goxQisg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="dooos/xL"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.43 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=1722525272; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kz66FuU/ARttOjZqWZbd30k8H0yCvS1lmutapB6qkKo=; b=g0ZEDYE9Eo+heTMYw5VVedRn1/nkgCUmc8mrJi5eNm7pqTG1gzgGA1RTgD2Fdgd3WGJL4t AfcT0tlc59q87/9h2wG5kmfM6ToGJMF44WLXRU/D9HMVYPz78b3R1OcjhJMddpq/ShIkiu wkdyMbYUxyvLs+UkpXIXJAO6eU50ttU= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a7a9185e1c0so716958066b.1 for ; Thu, 01 Aug 2024 08:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722525317; x=1723130117; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=kz66FuU/ARttOjZqWZbd30k8H0yCvS1lmutapB6qkKo=; b=dooos/xL6PjXV+OKRjTdpPFs2PjSbHXxtvy7Q6VOkRaTMtOgJo+EDM/GnLDQk0K440 cS+iD66jBS60VNy6AI4MBYfi7se4mqUeW7/V/gLtMY9Cg+7yhPRgSxnYx6qWg5VtQKi+ DO9PiZgM4+hJM/1AJoSaxXv2B1MNtCWQFqZN6d+ysr+lrze96RGJUKpLvsfwmxOTgZi+ HXscNrDFnNWB6uwQN08kMl0M25AIYeyGejfhP7c6Trtksxb5U/wVB9CEPBNMZLbZGMpw qagqzTasM2/c9YRD8dY1/9DqhK7dWig3wTP2/YP4TT+j9Cxeyq49MdxKJ+qpjBiZ1JPJ HfCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722525317; x=1723130117; h=in-reply-to:content-transfer-encoding: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=kz66FuU/ARttOjZqWZbd30k8H0yCvS1lmutapB6qkKo=; b=aBr0Z3drplcoOiLdaqb2pv6e+vgLn2Y43IboDbI7/ESP0+Ugwpl+CpkGJQp7Irlkj6 Zas7cW/3OBdi6HyuXEPhnPA+eQWSkqhXM+My4QGrf+M7dDR4arkdWXZLfLFvIJKNOcOO qawOIlTUnppMLUingtNtHZza4p6GHFAqwbUQ398XkxzAMFXOjVKKarj0oVo1qGumoFpA W8/1TXECQKzx26L8EeKirZIKvjJLtLy754/0kzuFm1hog8/d8GE2UXT8ESnO1kEM7AEU BGHyo9HNpD9XpgM5OWEqc3pBSmoyYvJfzWgJ8wva+042wha8vh10TLfM5GrhLzTILBw+ g3VA== X-Forwarded-Encrypted: i=1; AJvYcCX05GEJCQCqT/J21Icj1dSmIyEEwLYNHD8neVpx0Z5WNOH9heKh/s9aAhACNbsd/83TEpvKn9oX4Ljwcpo98iCg2Hs= X-Gm-Message-State: AOJu0YyOV399HQ2XGfkyJZU3iaBj1lcaXG6izyXQNDjD+bzc6yU3i539 xzpdL0VHGrQy7kmsLv+fjozPg606uTtMUzUHOPyngIDACKpcNcH7 X-Google-Smtp-Source: AGHT+IEppeybcKSETEZ5zmIwCIBD+KqgNyxaSp2b7YPCA2K65+OU77JOwmEz1c02mFRC9iOAzsvAiw== X-Received: by 2002:a17:907:724b:b0:a77:eb34:3b4b with SMTP id a640c23a62f3a-a7dc4dc02a3mr47413266b.11.1722525316792; Thu, 01 Aug 2024 08:15:16 -0700 (PDT) Received: from f (cst-prg-90-207.cust.vodafone.cz. [46.135.90.207]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7acad4146dsm907559566b.114.2024.08.01.08.15.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Aug 2024 08:15:16 -0700 (PDT) Date: Thu, 1 Aug 2024 17:15:06 +0200 From: Mateusz Guzik To: Josef Bacik Cc: Wojciech =?utf-8?Q?G=C5=82adysz?= , viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, ebiederm@xmission.com, kees@kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kernel/fs: last check for exec credentials on NOEXEC mount Message-ID: References: <20240801120745.13318-1-wojciech.gladysz@infogain.com> <20240801140739.GA4186762@perftesting> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240801140739.GA4186762@perftesting> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1424A180026 X-Stat-Signature: 89mkexn8464dph4dubrkagnzitgw7b55 X-Rspam-User: X-HE-Tag: 1722525318-250868 X-HE-Meta: U2FsdGVkX19Ps0s7uX6BGQhDNxtH1XLlLyw3yNbazRfO0TBscVKGZaejZcxCZzDNBXezIG0hAhu3yd+dLJCPxsCetSqGBhE40igXT5CE67Gl7kMC3++f2hRxhOQ0BuYpG7aD3i3qh/vo5aRF4G51juKGba0iPi2V1M5RvIGAb5fVgxv5K1/yEibYSkVcA4/5XtfkU7c70U+L9yOcpygla5UQy/uaBvVUCOyP+bvbb/MC7w9mRmakmMOR7VDnAvPZH4ahuvmWga44JH/Wa3iG9JtADygZdXX41nMhuziOaq+3wH52gU4HmF7dX6i2xj4EQg+O6vNSoVxCDdUWGFF2PeJXD2ZZJ2sQo4C1K7SQKfmMBNOyXrMX3FQ6wqcwUYMRWV9RX966r47moeLTdc/Y7vkcClTC34W1RiQsuhlL+45IMi4cru3Hi/KTkvxFIQls1tA8lM5un36Ly3q+C3B5DPky0uH6RxQav5w1bQtkvJdNDPIBJP/VuGZ+s4TuXNvAjhenrPXNn33BdoDyQX1zhR19RaDWlcs2i3i8oqIjzU+oTODIlZA7R2+AiVdYfEDehSiavFf6KoJX6kYVZIrk16k9X9zEwHKwjmZ8ZtpMXvxve6BSrjsjY4znSUX1+ZmbmwHmzhviqBQoS9it5X5fdT9oBQc8WHwIRvhy2hngkZnPXr5Q695yw5WORpBYNqya0Epl1G2y5Paq/08oa8lIUtz60LXrpOMGpnTEnj8l2T01cKyJBiL6tw5Va5DoPjKVyHxOKzeTgExN9+wRvZDQ/Ez7drRSkMS73369faCO4pon2h7AVrEzSAAaF74cIma5/yUoEOYiTYAjENA70e8OkzzZ740kfm+DOCYq5AojalehxmbjoIMoomq21HfVTadz3lXTA2j3HTJrLYhuPcHb374oTcNCJIkJupb4sju+wl4z3C2hbacFjxvhx8rQuhi2SMbST59GzpSQRi3zi2H ZbY87m69 3HVtoZfkRXfvr82FJYOKfUF0vWKqR7TXpBWR1k/g1482d1ERlq+ocVJ24yQJMPsAv92RDR47N4p/8HzRjzU1JDydZ9IaEsAcT2dtJpggEHXrH5hBYZ+zjsrvsEN7H03z7eawlZrV/WeG4xzvdLTYefN2/OPR+z2CXPgfbmJ3Z3jZ3nmJWUpPrxXF4OdInqofy/dzQq+c3BhXbU7gqe8Xvrzasvd7KdrIv3wY+qxpTRNgHm+3dnXP0bpCTVKreQ5XCGQAxnj/bfD4hJJDIMgr/j84noZjqGf3yg5WwhF/nmaV0npmPa/mIkOF2B8EDsKNdTJpukqcQG15kmFSrFRSePO6/x4EavOf6/543ZCai2suRolF+d3eFC2AxWxpZjdB7X37h41WdiJs9LCeo2SLSWs4yFa1G/snqktgKkBtGhBvUpvpnYM68qto71QvnrX3/qNo1dQBvUAGe1Gg= 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, Aug 01, 2024 at 10:07:39AM -0400, Josef Bacik wrote: > On Thu, Aug 01, 2024 at 02:07:45PM +0200, Wojciech Gładysz wrote: > > Test case: thread mounts NOEXEC fuse to a file being executed. > > WARN_ON_ONCE is triggered yielding panic for some config. > > Add a check to security_bprm_creds_for_exec(bprm). > > > > Need more detail here, a script or something to describe the series of events > that gets us here, I can't quite figure out how to do this. > > > Stack trace: > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 2736 at fs/exec.c:933 do_open_execat+0x311/0x710 fs/exec.c:932 > > Modules linked in: > > CPU: 0 PID: 2736 Comm: syz-executor384 Not tainted 5.10.0-syzkaller #0 > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 > > RIP: 0010:do_open_execat+0x311/0x710 fs/exec.c:932 > > Code: 89 de e8 02 b1 a1 ff 31 ff 89 de e8 f9 b0 a1 ff 45 84 ff 75 2e 45 85 ed 0f 8f ed 03 00 00 e8 56 ae a1 ff eb bd e8 4f ae a1 ff <0f> 0b 48 c7 c3 f3 ff ff ff 4c 89 f7 e8 9e cb fe ff 49 89 de e9 2d > > RSP: 0018:ffffc90008e07c20 EFLAGS: 00010293 > > RAX: ffffffff82131ac6 RBX: 0000000000000004 RCX: ffff88801a6611c0 > > RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000 > > RBP: ffffc90008e07cf0 R08: ffffffff8213173f R09: ffffc90008e07aa0 > > R10: 0000000000000000 R11: dffffc0000000001 R12: ffff8880115810e0 > > R13: dffffc0000000000 R14: ffff88801122c040 R15: ffffc90008e07c60 > > FS: 00007f9e283ce6c0(0000) GS:ffff888058a00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007f9e2848600a CR3: 00000000139de000 CR4: 0000000000352ef0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > bprm_execve+0x60b/0x1c40 fs/exec.c:1939 > > do_execveat_common+0x5a6/0x770 fs/exec.c:2077 > > do_execve fs/exec.c:2147 [inline] > > __do_sys_execve fs/exec.c:2223 [inline] > > __se_sys_execve fs/exec.c:2218 [inline] > > __x64_sys_execve+0x92/0xb0 fs/exec.c:2218 > > do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62 > > entry_SYSCALL_64_after_hwframe+0x61/0xcb > > RIP: 0033:0x7f9e2842f299 > > Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:00007f9e283ce218 EFLAGS: 00000246 ORIG_RAX: 000000000000003b > > RAX: ffffffffffffffda RBX: 00007f9e284bd3f8 RCX: 00007f9e2842f299 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000400 > > RBP: 00007f9e284bd3f0 R08: 0000000000000000 R09: 0000000000000000 > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9e2848a134 > > R13: 0030656c69662f2e R14: 00007ffc819a23d0 R15: 00007f9e28488130 > > > > Signed-off-by: Wojciech Gładysz > > --- > > fs/exec.c | 42 +++++++++++++++++++----------------------- > > 1 file changed, 19 insertions(+), 23 deletions(-) > > > > diff --git a/fs/exec.c b/fs/exec.c > > index a126e3d1cacb..0cc6a7d033a1 100644 > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -953,8 +953,6 @@ EXPORT_SYMBOL(transfer_args_to_stack); > > */ > > static struct file *do_open_execat(int fd, struct filename *name, int flags) > > { > > - struct file *file; > > - int err; > > struct open_flags open_exec_flags = { > > .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, > > .acc_mode = MAY_EXEC, > > @@ -969,26 +967,7 @@ static struct file *do_open_execat(int fd, struct filename *name, int flags) > > if (flags & AT_EMPTY_PATH) > > open_exec_flags.lookup_flags |= LOOKUP_EMPTY; > > > > - file = do_filp_open(fd, name, &open_exec_flags); > > - if (IS_ERR(file)) > > - goto out; > > - > > - /* > > - * may_open() has already checked for this, so it should be > > - * impossible to trip now. But we need to be extra cautious > > - * and check again at the very end too. > > - */ > > - err = -EACCES; > > - if (WARN_ON_ONCE(!S_ISREG(file_inode(file)->i_mode) || > > - path_noexec(&file->f_path))) > > - goto exit; > > - > > This still needs to be left here to catch any bad actors in the future. Thanks, > This check is fundamentally racy. path_noexec expands to the following: return (path->mnt->mnt_flags & MNT_NOEXEC) || (path->mnt->mnt_sb->s_iflags & SB_I_NOEXEC); An exec racing against remount setting the noexec flag can correctly conclude the file can be execed and then trip over the check later if the flag showed up in the meantime. This is not fuse-specific and I disagree with the posted patch as well. The snippet here tries to validate that permissions were correctly checked at some point, but it fails that goal in 2 ways: - the inode + fs combo might just happen to be fine for exec, even if may_open *was not issued* - there is the aforementioned race If this thing here is supposed to stay, it instead needs to be reimplemented with may_open setting a marker "checking for exec was performed and execing is allowed" somewhere in struct file. I'm not confident this is particularly valuable, but if it is, it probably should hide behind some debug flags.