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 52F7DC46CD2 for ; Wed, 24 Jan 2024 21:41:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E190C6B0085; Wed, 24 Jan 2024 16:41:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DC9826B008C; Wed, 24 Jan 2024 16:41:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C920A6B0092; Wed, 24 Jan 2024 16:41:29 -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 BB5246B0085 for ; Wed, 24 Jan 2024 16:41:29 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9102DA2162 for ; Wed, 24 Jan 2024 21:41:29 +0000 (UTC) X-FDA: 81715526298.29.8F30367 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf20.hostedemail.com (Postfix) with ESMTP id C33301C0005 for ; Wed, 24 Jan 2024 21:41:27 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LEea1S1k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of jannh@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706132487; a=rsa-sha256; cv=none; b=kCI0LNU124YKuTXnSf4aMj0ckpWPV4YixFB4H6VtvPNSqtRa4PGDo6/U00ZddqWGIv5q8Y X5l0383Clh9cXSPNNB8p/iINOFontHNohFshWtpusWMJML8B/wq9MDTBUR0VfUT/3cC+C6 hFuLIORCMEFB68fan0O1SxQNy9cnT/g= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LEea1S1k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of jannh@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706132487; 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=NToZqtE5w7bxKN+3pRr0bsg8tIkz9lpNWRvoqa9C32U=; b=fOYd3I8XCNBIW7xA0AgtugddxL98j+Hi3i49cHPx3C0mvRyBYHKKnZZtZ95sSnIbYi4Hce d4StQnrkFxEp6lEPXzKfxcDOED5dJ7LcbFZ6BFm0BaSd1P6HSZ2STXg6caaW8Aw6LA2sRT k9yPn7BinxzVidLDsrwiLjerHboacZ4= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-55c89dbef80so650a12.1 for ; Wed, 24 Jan 2024 13:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706132486; x=1706737286; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NToZqtE5w7bxKN+3pRr0bsg8tIkz9lpNWRvoqa9C32U=; b=LEea1S1krIwjut6JUYpF+G/HilA0fsaLs4N/p0S1CMr5M6JbMzERP1yUQBHMagHYGG V/mqsuyMov7O1sUIkoFGZo0UnC1Mx6oSTLSA70Chax2HHUdD0+zRO07H/H0ntiN6WJQq 4MLgMOV6RaY2QTp+OIT8JN72Av0TX7LjbQoWeTXtq6XHHwSUQ/5HsYmNCErBXntkZUIF iJmthS+0kzRw+3n6Umr54+OApnsFAWHZcnAb4GiT05da5zfvrV7htBiV58yR8/EOHQdB eF2cjsB7dKIMwOUPL92o2YJUAllxvrbI75igUoDZvHQ7eGSof7cfnr3wZkXpaXD0+AbT 2Sag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706132486; x=1706737286; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NToZqtE5w7bxKN+3pRr0bsg8tIkz9lpNWRvoqa9C32U=; b=TjC1BNdxdYNh42pckjd1fPEW9S8MoyyUnvy5KIoE3x+NfUJBtBtWDK3Te3RjBBUAAh RVrPLwTIVo31O9cAAze/A6QGf5O0ymuEIy7cUuiIft5LBiKMvxBP9OyZw1Yd8YV/nEMG g6oyZ/6ctf1FfI4t3nRWJjNkdr/T4F9Trdu0cWlZMrKAKwW85Q2uB3/yQaHM3yKQq8A/ CIj3nW1PS6v9BISvd5C1rdOKwI+i3God9DySmL/zaZPN0uhS2KiWuj5YaB9WfrIepdoe D4mEqTI158UvUpB3RFECfYohdImImUciiOPvw/X1tfM/c1oKwJMZ/oF7BY+1cBBP11Fa VJQg== X-Gm-Message-State: AOJu0Yz1WHUH4DzC/Gn5lp9kR1+RQwcaeEiMn1RkaorGGmS5bPPedvQL 80e7BIvdfzNmPQEY4I18A5HG4fB44ia1v3fQZZaCs00dXO5PiglxmznCEcEiOn83+Qgk4y79U0c R8WLvnz3+QRHs/XqUxLOrIKLDEa2FuQYxv5uC X-Google-Smtp-Source: AGHT+IHauIX2Vpg/PHzzW0JTV4fDFuqXAIYuBOadb1Lhdqvm+7hcjrHyfDr8nUiI/Qt4r1fFyqSNf90c4QBY22tL2Fo= X-Received: by 2002:a05:6402:290b:b0:55c:2493:2b31 with SMTP id ee11-20020a056402290b00b0055c24932b31mr11642edb.3.1706132486242; Wed, 24 Jan 2024 13:41:26 -0800 (PST) MIME-Version: 1.0 References: <20240124192228.work.788-kees@kernel.org> <202401241206.031E2C75B@keescook> <202401241310.0A158998@keescook> In-Reply-To: <202401241310.0A158998@keescook> From: Jann Horn Date: Wed, 24 Jan 2024 22:40:49 +0100 Message-ID: Subject: Re: [PATCH] exec: Check __FMODE_EXEC instead of in_execve for LSMs To: Kees Cook 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C33301C0005 X-Stat-Signature: heuqyi4hc4b9qiffkbgiymicy7fps11m X-HE-Tag: 1706132487-212751 X-HE-Meta: U2FsdGVkX1/aIehhABVCdErsqHIiC5ahkVh/uujou2KnL4knw1ReNEBt47ythj6IGLAdOTfmieuPB1FRUKp+UN9b2cO5wyHhHN4xY1x9GaKnkj2CqGitIwVwh/Wv8iM0Y5KZHS/4QuuhG3PE+hi08f3Ld/us5XVPnnVQHGcey7G3ylnRIw6WS8Zpjd1AKhtEqr51dUkmBoKwSLkJRKLO0/lyVH9SiqXKP1JfrTDmr+vOhiZZbTmo2TB3fxrOourN1aAVGwci1CKwqYKxlTn+xN/V4pxhgsBMFzFc18V5GiwsjZvqwsH28NEOaALeqSQO1GPye3DGYQPzNjAWTdUZ+L8YmRsr28ok+QHujSCDgBTSMZZGYJ1gw6AYzs32bZTn+c6qgDLW4Fck+3Ygp8+75lqtedDFmxLkBEcOlUaVx2qF5eeBBG2jlBeSayu4tgriUbz62/gZcqoDIvvWczL9AH4Amu3hbHVMu23YTdBEZ6QLwBCRXZ1ssPe0JmVjYMbqJ82MVD/Opr4d7fq3QSKRrN5wTiuyDw6UrKgEKKMWOvBrL9SQhkbKXe1Ww5ClQkHlURZdO35YIRWi4RwBaziYtntCFS13AFt76u9waeB+gMsjgNGteSRaWLwBm/0TpVPytt2gWuqhL59MEj3vVI7GuwVCLzOJqGVdxNqw6mvsTPe8kHoOdU1IZrRNrAT210Y5eUuJN9tE6UdIyo7udXaXd1N9hvV6bEM3SS0waE47UEblEIthaLeSYobeco9jBMnuKno8mLg447uWHbmxpqCMNvIa4+cTETF0zzbv+gg2ek6t0rsAoqs9zpCJv+TWLtMtI7vX7jhxZIVIXZTF+2Pcff4LqXx2IQBl/2A/JrbY28ZA9mUKgN0bDqMHKMlO5QXNOgybRDh9KSXkiJqcI9xCv7SWrMIEJkYndXZ71agEWUTJYp8+UvvxE1QAYCBU+ArcS9uHFxA0wXNRP+yN2UU s60MIhj/ /4DltkwooVJcmWAOOf+p41JQcX6ni9Gs3MCHd4dtC8EkwL6t5ZTcN7sjnPd53UbmBSQxUBhO8dEnroyQmJCm7EbjYdbA3pov7BS9U17z4pb0t4Yvh7h/RcZoXvxjfw0VGfRAP7fRUmJ6xaTZ3pRw5GCNoDDExmU09CPrHUqgB5mtr/mRv0y3g3Tt7Lz+jtPk+FZVWvDS+5anJ6jdmE5wyIkiVoYhLmVn5+KKBVfDXClAccjpz8cFbgFb4UlvSsbyH+IvtcX68GonMgQF8dCQJnRdCJbFFbFnOsOPSmCrnrwNqEcsV+c+RWYocPTkFlqbROslZXMTPMFSWnKNK+FcUC3ubGQ== 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:32=E2=80=AFPM 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 =3D security_mmap_file(file, PROT_READ | PROT_EXEC, MAP_FIX= ED | 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.)