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 4466AC46CD2 for ; Wed, 24 Jan 2024 21:50:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB2946B0092; Wed, 24 Jan 2024 16:50:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B62386B0093; Wed, 24 Jan 2024 16:50:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A030A6B0095; Wed, 24 Jan 2024 16:50:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8DD4B6B0092 for ; Wed, 24 Jan 2024 16:50:34 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 436A5120CB1 for ; Wed, 24 Jan 2024 21:50:34 +0000 (UTC) X-FDA: 81715549188.22.576CEDD Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf28.hostedemail.com (Postfix) with ESMTP id 632FAC0020 for ; Wed, 24 Jan 2024 21:50:32 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=g65Nz7AT; spf=pass (imf28.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.181 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706133032; 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=aKbTsnLJkm2iKuMS9jJ6ekbfLtHs2opAYqk/RqQaX2k=; b=A756iqFJphYlcUVmnd9R4adkhl/KXcCh/mcBFtB4QMkUC+nFhBqmh6/db7DRU4CU0oy82W b2kpPI8T9Sf1ZgPEA1uWmlAx1V8JBdu41C/wKPTUfMeGQL8YStSQqDzv86bc4vNH85c54X Jb7gZxMTpSiuyyYcjL3s3ZsqY9poa+I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706133032; a=rsa-sha256; cv=none; b=l3cw8iGk6lAp8dZUehNs8OSSgn1UxWzgOd0ZVNP6hLxeaxnjTTI/IBx85GbiK5Xw+IVxbO sQYV/GWfXgCI+837uuwqStVBReg3PFMo7LipKv2XoeTzI/4cX5rika8hqCqHKepEwYX5MR MmLKF6s8Vu+SUTQGl0SN5sRsj3cu4iU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=g65Nz7AT; spf=pass (imf28.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.181 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1d731314e67so22268295ad.1 for ; Wed, 24 Jan 2024 13:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706133031; x=1706737831; 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=aKbTsnLJkm2iKuMS9jJ6ekbfLtHs2opAYqk/RqQaX2k=; b=g65Nz7ATjsCRzL3eedpLjduUoQ+UOsXXw9wvXMmUKX8xTNaXHN4XoKMhPGtF/hxtW7 AytkBOb88qeNal+Jji4ieT+Jgd5zDCYifkdhiKOKvqxtMatwvShSjnR1jDq1Nkp7yWjB seUp38bj1AMPQYXkbg3RpXD2GYfN9ZjYQzESU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706133031; x=1706737831; 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=aKbTsnLJkm2iKuMS9jJ6ekbfLtHs2opAYqk/RqQaX2k=; b=iVpsAEQ3DZv6OWgR9Am6R4k/w8UZHDX/nSRmQq+6jWdBGEJSE1CxB8vrMHixAPD54m 4TO0TjQWxcFw3VSpSFLu4qoH+cxZJH7rbIvMlChTOmQizxGfajVZx5IJ8idURr6uws0N f/57eduiotSbyIFb9KqdT6FRGMYDkPsaL5vSoqk2D11UU+OAFmGWo974fisoc0JyAzO3 MtTh+7yA6M6Louc2yUBprXmExM6dFnXSoUgddE1XXktZiEAVsI7NuwDHI9yflN+5LC7z ZH/eVFUkoMW93sLl1tLxQGs5rGLQD1pC4Sxlj2sjBjyQKf+ExAoqvC3Ms+R0xBWKmIKl Zxiw== X-Gm-Message-State: AOJu0YxFGYX6+G44N1yaPS7FhSIlpj1Z86PqsfSpRjQsNINj2tHRWLP3 k726i1L35/SAMQOv+QcqgTKoDhzMFKDsF4tnAadFnWr4oN6xswPEO99hjBtf/w== X-Google-Smtp-Source: AGHT+IETCk9PNhDkJerT9hVfN75xLknukOIbsiWCq7ni0ocP8Kl19XxlMkq1LihioaB/wGqFl79jjw== X-Received: by 2002:a17:902:ce83:b0:1d4:bba1:bc61 with SMTP id f3-20020a170902ce8300b001d4bba1bc61mr22180plg.119.1706133031248; Wed, 24 Jan 2024 13:50:31 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id jl16-20020a170903135000b001d75cf0e039sm4692075plb.18.2024.01.24.13.50.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 13:50:30 -0800 (PST) Date: Wed, 24 Jan 2024 13:50:30 -0800 From: Kees Cook To: Jann Horn Cc: Linus Torvalds , Josh Triplett , Kevin Locke , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Kentaro Takeda , Tetsuo Handa , Alexander Viro , Christian Brauner , Jan Kara , Eric Biederman , Andrew Morton , Sebastian Andrzej Siewior , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] exec: Check __FMODE_EXEC instead of in_execve for LSMs Message-ID: <202401241348.1A2860EB58@keescook> References: <20240124192228.work.788-kees@kernel.org> <202401241206.031E2C75B@keescook> <202401241310.0A158998@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 632FAC0020 X-Rspam-User: X-Stat-Signature: 4ydiozqfdfp6m4gtxosiwrd34pyor4ax X-Rspamd-Server: rspam03 X-HE-Tag: 1706133032-171264 X-HE-Meta: U2FsdGVkX18DgkfL8pbhcwPp/LhHKDX73oKfKTczGV4ng3Jj/1tVe8ShZcHx7/5ApJF+EwPoX1EHj3G1mMnmyIsf/3byAM14Aos66bZW3LwYhwXfbPVjE2qss7RG6+Rg/wmq6LaCywFiO5gabn7nxQWHMSxT7xmkiec77STy9cbcplc/7gswu9MjUGr5Cmra16hPqsrzwwUrMGoV7qsjyi4OG5JFaVsEdQcPAg9gifLibVC24LcFnVRi5HrubQ/uRe3gE3IrDWvgQHV7Kb8a8uAET4Pp6rwvmKBzHSGteI8brZ8rZmYCDOICt2AIe9dnYedKwf61p5aL07dO3ONIunF779jZUrdQR5FoqezBIwBl+iml3kUIJndlUShrDRjiOvGI0ftZEpuLk5Ou0ZR5zHEmfVy9+O9G68k8XweXrKkdtJaSaUfGRwJSSoLMZsk7ObqbH7GUkm0l4VE4V1ddBr3T7mPsthd1g4XDPe6+kQl/qr2bCja9d8Alm2HToNOMh0JtroNoqmHNG8NimxJFeT5vaCWuHBKAxJ1TOYF1pBHf3lLwccRCb8rdj0UwPlAFOPK4kIASo9jp9NtKSo+r2HRnISxlK8F36JWxvr1pMrskD8HvZ4pJrl+9hJzl3/hivfZNPeGwpjdnjZh3KgkMy6deXsBcajQeCKD4/hO88gtIo6b11HZzThwPCIE8W69nSIPv2GErs3e7LOMYeZ+Jk4yTpHkf2/tRHOs6ELNFY/61rI4YPCSX/LAFumIR4UTKgFE06hAHGiaBYDMkyD17OgICg0d9LX90sEPoUOLIcwbn8fyuvafxK6InpKhyJdNeNbq2cSjn3RMwLLhVhPijs+icFb57UL52i2B29Ma2lg0wdRZXxsXVnOXTirAcAxb4/Doe//8Y2YQ3XxOH0W649nvmxzhuB7OuiJ9jLgsdZfAIG0BJY2/smGGm7l+AfEKHZ6xIPOpgRjPQ9oovLVf f6yHyZmH 3mUAIpSCIFmrcBgpPAlOXL+ellHaibC69gVC/auAbEEN1dl8bMNgpodokR4vuLyPii3080iuykDIdwmi36EzMX+518/+h/c/FUg6qz/+NnfoLP/f2X9GuxlCRgfPJKnM14BurGlsRR7Bnrz9R4aPXSD4MLxkZrO9CSNYVYupIyqdk5YA/R0KwU86Nn6zo3Xs1HGeGPzLL7GQPe/C+ZLapEdltE1jL7rPzxvemrxog0rW3DXf3ByfM02r5GmgJYkdYsVszkv7oL3AYNL1JE3etUW1yfjgdJoysqOppFCpofl1h25aBwY0GT26gvlO4Zn0NLBrT/oCK+XcTos08OCc3bb+NhfHLKRg5tI8/Tgin3cb/XjT62ejEOejC/410PHPhgs0LwE4D7o2CgrjKLJYNR2rp4XlOa509uLo0j57HQrqBLlpnoOiarUMQzmKH6QebFf2HqVntHKy8tXM= 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 Wed, Jan 24, 2024 at 10:40:49PM +0100, Jann Horn wrote: > On Wed, Jan 24, 2024 at 10:32 PM Kees Cook wrote: > > > > On Wed, Jan 24, 2024 at 12:47:34PM -0800, Linus Torvalds wrote: > > > On Wed, 24 Jan 2024 at 12:15, Kees Cook wrote: > > > > > > > > Hmpf, and frustratingly Ubuntu (and Debian) still builds with > > > > CONFIG_USELIB, even though it was reported[2] to them almost 4 years ago. > > > > For completeness, Fedora hasn't had CONFIG_USELIB for a while now. > > > > > Well, we could just remove the __FMODE_EXEC from uselib. > > > > > > It's kind of wrong anyway. > > > > Yeah. > > > > > So I think just removing __FMODE_EXEC would just do the > > > RightThing(tm), and changes nothing for any sane situation. > > > > Agreed about these: > > > > - fs/fcntl.c is just doing a bitfield sanity check. > > > > - nfs_open_permission_mask(), as you say, is only checking for > > unreadable case. > > > > - fsnotify would also see uselib() as a read, but afaict, > > that's what it would see for an mmap(), so this should > > be functionally safe. > > > > This one, though, I need some more time to examine: > > > > - AppArmor, TOMOYO, and LandLock will see uselib() as an > > open-for-read, so that might still be a problem? As you > > say, it's more of a mmap() call, but that would mean > > adding something a call like security_mmap_file() into > > uselib()... > > > > The issue isn't an insane "support uselib() under AppArmor" case, but > > rather "Can uselib() be used to bypass exec/mmap checks?" > > > > This totally untested patch might give appropriate coverage: > > > > diff --git a/fs/exec.c b/fs/exec.c > > index d179abb78a1c..0c9265312c8d 100644 > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -143,6 +143,10 @@ SYSCALL_DEFINE1(uselib, const char __user *, library) > > if (IS_ERR(file)) > > goto out; > > > > + error = security_mmap_file(file, PROT_READ | PROT_EXEC, MAP_FIXED | MAP_SHARED); > > + if (error) > > + goto exit; > > Call path from here is: > > sys_uselib -> load_elf_library -> elf_load -> elf_map -> vm_mmap -> > vm_mmap_pgoff > > Call path for normal mmap is: > > sys_mmap_pgoff -> ksys_mmap_pgoff -> vm_mmap_pgoff > > So I think the call paths converge before any real security checks > happen, and the check you're suggesting should be superfluous. (There > is some weird audit call in ksys_mmap_pgoff() but that's just to > record the FD number, so I guess that doesn't matter.) Yeah, I was just noticing this. I was over thinking. :) It does look like all that is needed is to remove __FMODE_EXEC. -- Kees Cook