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 B31AFC46CD2 for ; Wed, 24 Jan 2024 21:32:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF9EE6B006E; Wed, 24 Jan 2024 16:32:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EAA1A6B0083; Wed, 24 Jan 2024 16:32:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D234A6B0085; Wed, 24 Jan 2024 16:32:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BE02D6B006E for ; Wed, 24 Jan 2024 16:32:07 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5E8E51406E4 for ; Wed, 24 Jan 2024 21:32:07 +0000 (UTC) X-FDA: 81715502694.17.38D51F9 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf26.hostedemail.com (Postfix) with ESMTP id 7B427140016 for ; Wed, 24 Jan 2024 21:32:05 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IE24GJyJ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf26.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=1706131925; 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=XZl55Py4L+cX7dTYmA9QG7BMCagLiQPFiTbbjgmBFt4=; b=ux6cmaOuxOu50s4Q+QGROAcr6iVubknIBHzW5KdLwJZUSjgbA6TAvTH76p2YmFhpcRObzk Yqou+jbaBnuX/Cpuu88C71LPouDjOLGd1hiulfsSFAC1+T1ynK99K5AeSbVdK4vHdH7LTz luUJBrCkFEhZ5MqmJgruTSDboOaQ2Ww= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IE24GJyJ; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf26.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=1706131925; a=rsa-sha256; cv=none; b=YA3ICg052UYwuY0cdb49EtM6Arru6+H2q2Oi/RzkSgoLZsdh5zZL96MxL0Uk5JbY7fn36E tI1kv2bD9eFIxNUY7I10wcTjfHDpizEKeQR7XUR7+D1VS/y7yLcaRLwXmLrjacZhPTMtmi iVDnTfu8vkrZ9zloC/YIuL9aauNpwTo= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1d74045c463so28757065ad.3 for ; Wed, 24 Jan 2024 13:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706131924; x=1706736724; 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=XZl55Py4L+cX7dTYmA9QG7BMCagLiQPFiTbbjgmBFt4=; b=IE24GJyJ+0GL5lseq6tmvYlGk1buCGOfjUiQfNn764Ma5c+l6AYPVb1YHIIA9FU3W5 UB+GhPOVq9x1XNtpXfDe+nGm0HDeqBwy0ywOP2dIXNfEl/LEgNCA7K78EWVkk6z5LMAP NbcZT3BhMN0TCxNg29EZijhy94/eZx3Am8mM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706131924; x=1706736724; 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=XZl55Py4L+cX7dTYmA9QG7BMCagLiQPFiTbbjgmBFt4=; b=Wm4o17ZEq0ycEe8Jv8Xum5X777TEnfut3NXk5KcbAT4sQ+c1Z5qMYqBXGbBPnSuhdR yFBku+zFuE5rsPHvmaZXhYUT01fjQCqm4xBfCm/I5HBpl8XgAMVVJJGRxDR+gOGkb20Z py3QGWZHfkICnhFDdUpyfafkJi0eGcDY2nKAeEq2O9gidl13L25naYUIhTlrkf+ftnUM +JbEiZoCAaNGtxHjsECljE9kBLqRXUFqENrE0CJsnGfRJm7N1vmt1zhkCkKrTLlINj+J a7NRyoo22fkum3VWHxz2iOOzMMNACmSMf1SGO4+HX7+YBkvh0ypKL7j0XWSpfYG+HU59 iOVg== X-Gm-Message-State: AOJu0YzpfJkXqD1d2GZTZnmTGlru5WKqIsqjVv6LDMZ4oRagRzpHWqfP m8IYjd8GsbpgyBlrLPsr8u877FhgM2H6bx+NZAayyONSivoCbtHTLvasYV9Lng== X-Google-Smtp-Source: AGHT+IHG/m3jUrCwz1WR7nv7Vtv0Ytnd4VINI5aC54EhqBwHd/tZzwvFvQAGR+utJefrE8TrLXq/rw== X-Received: by 2002:a17:902:dac8:b0:1d4:4fc6:8d9 with SMTP id q8-20020a170902dac800b001d44fc608d9mr28810plx.60.1706131924170; Wed, 24 Jan 2024 13:32:04 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id u18-20020a170903125200b001d4ac8ac969sm10831633plh.275.2024.01.24.13.32.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 13:32:03 -0800 (PST) Date: Wed, 24 Jan 2024 13:32:02 -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: <202401241310.0A158998@keescook> References: <20240124192228.work.788-kees@kernel.org> <202401241206.031E2C75B@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 5d7tcf877f6ehmh9x4yobk8hx9oix681 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7B427140016 X-HE-Tag: 1706131925-873659 X-HE-Meta: U2FsdGVkX1/t1MMvwioGwcg/z1T0CNe8fOI8GQsWR+fYRgsewwWpN6yBFvsX9SozpwX6MZKKvEGsNXNu04F0zyii1yKDB2ZaA9Pssbz3id7mHgk5asoMeIHslKx4vMnjJ/rv2wT7xE7Bb9p6kuUCdBTYYIo4ojaNmnFE8HiEz7kmV8eIEHGWH7q2DJ7bhR83CDp0r9PyRSJWHRDNZjQLZV1JHSJ/gQUDLlD8eO7G3ocI4ijqt8AUfqgUI7xAaYhfPNfIZhNV1f5RO1AwJNSIAOxWONZYuAP9eian4H4PRXmnDRyENSrVjhOgjYUN4tqt8q1+jLYEh8jCf1Z1hZkRgN8JVKFi4WIB0KgVnOo7qRCmKmEouX7/mFZ84N1hhbgYu5peuA6FXJjJ4es7cXGRA33U4UGoNRmtnO9L9Wo5o3C+umCK/6Z9J+dqylS9QYD1owokqrmhWTz/F9pxaAxBcEntcR34QZrVE4vnHZD0ga4zI8CZYmO60wvm7BJN2LJbFNNE0ItDg9rceY8IUt6xr9kbVeT2dSqo3PIP5cOx+X47z34ncdmUZM6RzI95i1lht53ZFGHHl9zH40B+BE0IA/OtwJ2SzLydBf4b+n8y0eBgzuA65/s+dL+Q8c/VP85ub1IMrMwP/gkqRoZUDIcC2a11NJFKKtCYkngym4H8ZKw+EeO04hMucCjSNY1zjkhS2/XiIrqgzvf77xZYPVxp+Z898qWQWfe1gRFMNbcAz1ecrLtCJ9fjmPmqBjhob8tbyfgdrfuQP9CX9gNDXlMf7O/xRrHyHWA0aJHTwRSeyThtOa1xkmWNyVbC1vgfdVnY9BLdyTDGZrWeCBHMIlFXRuV0nu0CbT8HKBSygkDGWyGXragTDzfQiiSXlkSgoPzWnWsAxvOZiWsyzFPHwnkjp3EOm5A5L5HdtYGnvcdZmjIy0DLhuYss/CHfoGtFAUAHCkwsn8TV0gm5SK1D72L FsLleyGj 7Q0MObxiEVJbCxE4MM+CltPqLSKDSHmyOyRABYsU7iWioqUiSvft87Isfeog5GNfzgLJ5+C9TPoB4y8rk1T/AAVsKYFsiaOkJao+Ky1K2wJbvEZnPGOgfhZU4Rgcs2kZvutx5RP0/60ZiHqRauNAX3PWB84/PRld/nhUKEovsfrJwVXeTytrVAHv5pn2frUt6/V/P+ydGHZETxRwCPCs19DtVLaYiEttwzjSKTpXWhALb/M8AtlcGAJi+hwMT8fun3UcT8rb7uMFZWUAKcz0FlfRpbNw2UJvVGPAc0vGYn5NhcAHkYkcH/xxFPVQI2z9NNZaBt35L+YB5teKzzNTQzVleOqXd62Amilnt8Tu1YbCQKVfxNFePS/Sv5aqkmYyobzdtshplbthes9ACO/Wza/HKxxeocesU9xQfkFkvP0Szu9Y5EeRyc9DEjSYZ0QBZzry5crJZJTJA2FzZrvlfFhPFiqanWt1QNFhy27o4FY2H8/50OmSYVhUgh8BiYBrUIxBDquUMyl3A51c= 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 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; + /* * may_open() has already checked for this, so it should be * impossible to trip now. But we need to be extra cautious > Of course, as you say, not having CONFIG_USELIB enabled at all is the > _truly_ sane thing, but the only thing that used the FMODE_EXEC bit > were landlock and some special-case nfs stuff. Do we want to attempt deprecation again? This was suggested last time: https://lore.kernel.org/lkml/20200518130251.zih2s32q2rxhxg6f@wittgenstein/ -Kees -- Kees Cook