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 27935C47E49 for ; Wed, 24 Jan 2024 21:35:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E2F46B0087; Wed, 24 Jan 2024 16:35:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8929E6B0089; Wed, 24 Jan 2024 16:35:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70CF06B008A; Wed, 24 Jan 2024 16:35:27 -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 6013A6B0087 for ; Wed, 24 Jan 2024 16:35:27 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0BDB2A035A for ; Wed, 24 Jan 2024 21:35:27 +0000 (UTC) X-FDA: 81715511094.29.23B091B Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf28.hostedemail.com (Postfix) with ESMTP id 2FB44C000B for ; Wed, 24 Jan 2024 21:35:24 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Ez9MKRTZ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf28.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.176 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=1706132125; 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=R02kkjm9zZZALeIAu8OyIiBbwYldvv1po8aujCvgxCc=; b=KD1hViSiI4D2uCRHZcYwDGUvrGDvgvMYRB3lrqeXIW0Lf3lqG/7wU3O/gubAYJDu2MVZHX UMhL+9FpKZVvRslvSiONmKwfexegLrWDSPaN+X2uu3rz2+Ao/hiCOZxQooN4Y1jDxBxdN6 gxQyKZ43DlB1tyWhk9K96CiVvaKWs+0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Ez9MKRTZ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf28.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.176 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706132125; a=rsa-sha256; cv=none; b=bWmy4Ftot9TOUnxLB1L+HeL0R80McNucRYN6aursm8ftJTiJWOHAtzM52/avszgnV6FkBf Ai2sKmFuqygWUltbKQbhY7YESyOgIdlyTtZMDfzAn6L+3bUlbeCN/nRYHbOEFFoONGQM2t OrNwePM51g4HxVRqnAD5B0+Oxh8FtVQ= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1d6ff29293dso41834225ad.0 for ; Wed, 24 Jan 2024 13:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706132124; x=1706736924; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=R02kkjm9zZZALeIAu8OyIiBbwYldvv1po8aujCvgxCc=; b=Ez9MKRTZgwxhhnAwxuq3C51KtxRd9ZvOHMjO2VBNzE8CVbWsQKXGk9zMlLirtTlgep ng8MOHXjIE7O+tJQ4c8JKZ9ozNJvIRMQ3O4I3nhr0sr0Fpvs7iFYtTzFaQnCNQ/Q55UL czRyTRHusBBqDqx5uVCIZ9k88xWSp+q979tYo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706132124; x=1706736924; 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 :message-id:reply-to; bh=R02kkjm9zZZALeIAu8OyIiBbwYldvv1po8aujCvgxCc=; b=H9gi4mF4Miu3M7Frn+Vk2MNQgd+zgwoCCuMJIEOGDjCMX5r0ZmOJHbWr1Sbfb3JVHY cPY0+Hy/NIokK37h9owjiKuq83pz4gEqeK1LDZ86dRwf0lUA607mRX3g00flQews+29P At7zlYtKbsjfpRpprE2b7hZH7w4KZEdHgEaPcNUBiZxM0VfTenclROKjSfYUc3/7T2dE u3z5T3q0sshYMZYY/pY0ydJsNSWfR0ZAXs/cZ3q6/TVjAzsbMc/FonviHPIikbgx7V8B TPDZY2ow9m7tv4BQ9E1tFecESE0tdZGmo64dN6yDkOvNSxI8EVjTAsC1Obsn0kLcf4N2 b4gA== X-Gm-Message-State: AOJu0YywfPLqueQp4vh++OZsbHmvE8o14jVaJ+vX3iEkNpYVHNy0rqL8 FWGcJt2KgZCz/+CrWAFsHeJhIBb2ITU6GEPmUrWUlpDlesYcn3n9kaPtJsJvHQ== X-Google-Smtp-Source: AGHT+IHcICz0Mfn9SvjnkuBQXJnezLd9Usm4kNxOTm+k+tyC0AhF5zlKsrJeWSD40yUZv9HJJFvwgg== X-Received: by 2002:a17:902:ee0c:b0:1d5:b82a:939 with SMTP id z12-20020a170902ee0c00b001d5b82a0939mr16459plb.125.1706132124053; Wed, 24 Jan 2024 13:35:24 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id mj11-20020a1709032b8b00b001d73a2acc2bsm6701572plb.142.2024.01.24.13.35.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 13:35:23 -0800 (PST) Date: Wed, 24 Jan 2024 13:35:23 -0800 From: Kees Cook To: Linus Torvalds Cc: Jann Horn , 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: <202401241334.670AFDD@keescook> References: <20240124192228.work.788-kees@kernel.org> <202401241206.031E2C75B@keescook> <202401241310.0A158998@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202401241310.0A158998@keescook> X-Rspam-User: X-Stat-Signature: n75x8jbse4s9bsb7aw5fyjkwf1stx4tq X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 2FB44C000B X-HE-Tag: 1706132124-969462 X-HE-Meta: U2FsdGVkX185qHqp2LMewNrXyN80jNTWYoA3dqKVUSwN2voubMvU1SEbFZ636PwN/RIkVH9vSvOI61iz27nR1otpk3UkEOz0IjabVIx7cUH76SBneF37L7gwpXZ0tvkJHWWyfIti+NTwPa/kcS0RrGK1mEmldhmWXWM6q8zcZhakpZghQKfPuCBBupqAuywnO/EDJ9Og6FoNIF5snqjZOxVOI7GEqNF0fSRA9sSESQ1CSFWyuOI8VzfNWij9YWB9xcImADxELfbFSSZx+kjNDOa8xeb5ND3ou9Cfp6/X4ULKjgnM0zxbDyvLYWz5zIV081mSRiH0ixMQWlGppOsg1K/G6kfDX4304v0Rry7pbWWfgvD+ay16lIwEgcqwAYtXpMirbPn2wbQkoUAIF3TZ1/9gYB5ZpbyoSzCI+6rjCEtFMIOxKzRv67cPK0i+9cfdWJJZBoEjYGVUgZ93FRS9Rw+avi0VAS9K/KI/Uf1wbpf7zF2QwOdckCm7TPzSYcty3/1rfJIGDrnmnG38idURyj+ZtJLy34X62HNRfJbOCbaPgnBEPy4d5z4RgXCvolu3iugCfu/TT/IvyWf2wrzNX4ifa5wmVjGN420hriKx36MBwDoU3/zm/S5IaHJjfliuO7ku6/GXpoaiTrNILNkxzMpbO6480tohH57sDwFacgPy/SMwSAOyK/Sx6XXpojzPjVkgfCFIZ6B6MMefckK2a3tZulknR2bFfWfqABKvWB0s3lCpXWCue0EGRciOITdPTkvC7NGAxrVf/fRgU6S24wVYafuHyqWFxUqF/sSW3hqmOrRF5yYuuK06/qWbd8+hgkRQMBdSP3CRM+lN2HYFw6TzQmoWkYYagu6DvbgonqHPTJWYWGLZ1PI/uxtUkR17cJB7Cz530C/uQiyC7PjStKISRVxYsJDNCgHRL5GKBAK0U7paVsufsYsalLGd0dXj2cEvtIIYDGLypj0GPJJ 3sKkPP0h ZCF7zyRsBngzeZBer3gzDe/RUK/QWVKwO1Dba1BhP8BxqoU1cVB7+rTOvfDnBNOgKbaSXS1cp05VOPLEaAHaES3cHSD1VNbzQC1Dr+JqQfRMOEH810j0aQdSIlNbxH8Ou9agzxArqdpxWynylNDZXodo1C/uH83luaagbwZosas73mIeg5Fcow3oqwErLGGjDu2hpRg9Vsm5V3RIOBz5AcsqCWvfaCeLhnfLKAdacau9rwR7+k0M0fBTGrN5E2VB/fQ+VtrWErAYRFh/pxo6z6Ew496hyGEvTmuEL2XbAmPwzGCFdw+dKCEyXznB9cj2YB75HJE32GP93OrOv6+UTWzPmaiR3vxmFnUbIk/p5qiWoju+em3rcdjrbM4zRHhcq0G8XuoSldgL0sQiiXAvgXnz07PZJaBEUyczTRnBSHbAUzRmC52F896hyJwuLwDEuPMDAn4htp1mD2JY= 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 01:32:02PM -0800, 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); Actually, this should probably match was load_shlib() uses: PROT_READ | PROT_WRITE | PROT_EXEC, MAP_FIXED_NOREPLACE | MAP_PRIVATE, -- Kees Cook