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 8345AC46CD2 for ; Wed, 24 Jan 2024 20:47:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E454A6B0074; Wed, 24 Jan 2024 15:47:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF5388D0005; Wed, 24 Jan 2024 15:47:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C96E58D0001; Wed, 24 Jan 2024 15:47:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B6A106B0074 for ; Wed, 24 Jan 2024 15:47:56 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 89A1E160138 for ; Wed, 24 Jan 2024 20:47:56 +0000 (UTC) X-FDA: 81715391352.12.9264FB0 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf18.hostedemail.com (Postfix) with ESMTP id 7CAF51C0019 for ; Wed, 24 Jan 2024 20:47:54 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CIx1Tqga; spf=pass (imf18.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706129274; a=rsa-sha256; cv=none; b=Zag+K86GufxwPdxe26ETMGs8oeogvYPXsC/9OMEgdX7w/tdwNGdZ/DL8HLM2+jAMnUgAaP OXTb4zvaxqDrr3+LSSNbMyPG0S6OFilb0cz7YfaKBfRg+N1DKIseUu45FxLa3P/deaqy9w HKbmGiJCItoAhWTWXme6sxaCUlWdD80= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CIx1Tqga; spf=pass (imf18.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706129274; 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=Rk3ry+wMmO/dN2zz3UHRD0lGEi4syprX1/TUT7irM/o=; b=iz6fZRjsRZp9x2T2984iwEXF3+EWc/Wab2ABl6/pD4KRzbANxF+WxhV2SxNDZ8SXDl+DN/ 6pwXRkLB3HqZztTOknpvXOmMIfB4rINWoV+gin4fuCLrjKiOowTPbnv+SmYpKaItid8GlW ie8Zo0LHlZNbMmw2u6f2F7FQqWCPKc4= Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-55a5e7fa471so5387695a12.1 for ; Wed, 24 Jan 2024 12:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1706129273; x=1706734073; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Rk3ry+wMmO/dN2zz3UHRD0lGEi4syprX1/TUT7irM/o=; b=CIx1TqgaQQgWAhVAgFPjWHRYwiDqOeI50UjLF5HfuHIMAYOt3OVf9gmOw5ZNf360I9 DtThRUZYn/75VCdLzAoH8+RqtT+r2AP78jkbPmYM+2AO/LmKWubuX4nyQlXlDk5a8A1j 9G88/+jz6pKsToUpyqK2aqIZv/QrC5wjtvwmM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706129273; x=1706734073; h=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=Rk3ry+wMmO/dN2zz3UHRD0lGEi4syprX1/TUT7irM/o=; b=uS/kZXQgxXYpHvkgTvJsUB8vscLDCJtK20mVh9HY4KM77gFq/Kju5+OrPMFwltqHd0 eUMb+TibeKcSEYDVQVmEwdDdGkLanPC36ddSjRcZm9AhlmOfMLRsHIn3vHjwkwdEzs1S gSyorh5JFp37MSv3lgStrjoRWzOuEqHToRZCOF60mkoyY27YqllJzpjv4C5jEnvNnWFA 9sCsU2t8L75zXCgNtEVq8wt8We3l1HywmTrEYMvP38lbY3anwNZU2mFPFttuMpMD8EsQ U4y0/BKRvdhjbyDwCtuda2hqEtyjkcBzCr9LJUAu6bvRN69P9zGUZSJelwswicBqORt6 kndA== X-Gm-Message-State: AOJu0Yxwe0tHESTjCkNbr9jpD9vLNg1eAEN4bjkvdSJOJStlKsKrM4Sl VAo0Tip9eVV9TzBHlmIS3rg2QlbnO7cAzOCo8yyELKeIoup/iPygRueuiKEEsN/vTP2OWKaqjuq bCJxjRw== X-Google-Smtp-Source: AGHT+IFaPI+5zbFRM44gWJzXI/wxJOHnZwIUqlpQXOoBFNjcY/lJf2l9T29cJkRmHPLhg3ViUqCTww== X-Received: by 2002:a05:6402:1603:b0:55c:7415:1e1 with SMTP id f3-20020a056402160300b0055c741501e1mr16143edv.4.1706129272859; Wed, 24 Jan 2024 12:47:52 -0800 (PST) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id q9-20020aa7d449000000b0055a898c3156sm5670120edr.11.2024.01.24.12.47.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jan 2024 12:47:51 -0800 (PST) Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-40e9101b5f9so65455885e9.3 for ; Wed, 24 Jan 2024 12:47:51 -0800 (PST) X-Received: by 2002:a05:600c:4ec9:b0:40e:a3aa:a463 with SMTP id g9-20020a05600c4ec900b0040ea3aaa463mr1545745wmq.20.1706129271244; Wed, 24 Jan 2024 12:47:51 -0800 (PST) MIME-Version: 1.0 References: <20240124192228.work.788-kees@kernel.org> <202401241206.031E2C75B@keescook> In-Reply-To: <202401241206.031E2C75B@keescook> From: Linus Torvalds Date: Wed, 24 Jan 2024 12:47:34 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] exec: Check __FMODE_EXEC instead of in_execve for LSMs To: Kees Cook 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7CAF51C0019 X-Stat-Signature: 3jub5efwjz4zd7zifrzmy9mrmy16mhua X-Rspam-User: X-HE-Tag: 1706129274-663748 X-HE-Meta: U2FsdGVkX19KL0wc+4sgptUF9IkgWtwyiV5bgd+ZPmVYsTAxlwB3OLH+MnqGja8Zil+dt1S4rD15xCM4DTYYtv1LG2tLjRynO2DRXSdTedqAvVBqHY9O5bqR94t50r2StpzXvptBqpBvqILVBo1e/k5e0IdDw52YFNfNUMF8xFuU9aZlyPuJvD99fKkQ5LfBbSygBEdZBE13xu+F7a8SCSwkrPlyN0rghthhKjuXXXa+9D7wS02/fSsbuDUj5VmGAmPeNpZPzfqW1T7k0g77L35nSnRHQtGu4cAWboHyD6vA1an1VVDb6eMxbpPtaky93UyhKqbErXkfL1mBAxTsuQxdNbAC4Z2/vF7SQ17y74fl/I0pSyWufBSqN1IDGW6zqq1VLNVoMy1SCuarEsly2AXlzJyIVZLaZF573eDoPXwx13KRTbQS09llRWMKu3rS+sV46ZypYckMJpfbVkKoPlW715bOtlCiyuCoPb+McBwwVi0fIPp8yOyOI4YETDgjLQe2ZBiBMnezr+zx73ZkW9bWJuFa/wLsM1+F8ojP+1nNghzj8uK7ijOPuuZVqiwouVqe04X9PiDzGk7+3jnXJ/SA9AEvmZtLb33bUtScV2UhT6cEbenSii9y26fhpPdgknU2VkG0b3KbqaZ0d1xUuf7Vl/nXs7VN29eqODojPaD+ojtLP5M/49FVx/ES6AFQCr4buoA4DnR7Bx1gpLpooOsBiMjKGq2FZclk2e8iiBR/apgGAM06Z7ORIp/ogHRDmjPky/rEtIKv9bNaByCOKkQoKKzuECutmQEAwCoSEkpDsJnRvhAJKtC99nEJH26ouwgxmwcyE394qS1jGLtGmlnVm3oVKNSQZzLCkgmERzs4iZ9zCc1J53hT7o5Mi9ZxOvuHiE4rxCLuCmoyAyE0ANbF2T8aihW2Qfr/djtobzixDj+BFMCkDOSjPYUHH/Zhyd7RMh7xYU+7wk1d6jP 7DMzRGOr KitJlvEuzpT1UbgjP3WONZOzXKE9aJifLSsTo9ObymkTyX6cidJWwvmyRad6RKu+Fvm18Iygf6tqoNIfcDnJYaci78i4XYfXQfSheZSbnmfvtE45l2R1KRyHLY6Y3f8zoos5lnuxQND4SDQyZVTo0atl63adF0BPcy5i6FGqsty5Eh1Yz1W9eOqYeur5eItPZtAGUmc7awEGpWpUDPPEvKw7EiMwFU23fo8h9/9M2+m9oADf6H4BEorRLpAInB9nMK/Hb4RR9Z6Inq1H0a8BIDLOYzPf7iwuONC6IRnIlosRTkdDK2XeUOW5j8H6+8003nHGF6Ms6lCIAK/NSoVPM7aokTBu9n5QI945ArBzA6s4put2EWiVtfJojHDXSFdJqrOglRIoacyaz8Rmj05gxU1ta1SIDVXlf4pkt1CgEXg0W4yosPjxelbtKUCcfTWpWR+mYHY+clxV3KbVbShUIlmclw8x3xIuQbOnccUYlUjKLS0nOSZZSKmyZ++9uQbE/3aRfsUFuKaOHq4G2h0RM7FrGNx+toTySxayVef4RLLD0GQPaB/JERbFmAwSm/rxlBs+6lFYsSr0iJp+F5rL2QOLw+0PiGUtNTzaBRvztNkegeRs= 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, 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. Well, we could just remove the __FMODE_EXEC from uselib. It's kind of wrong anyway. Unlike a real execve(), where the target executable actually takes control and you can't actually control it (except with ptrace, of course), 'uselib()' really is just a wrapper around a special mmap. And you can see it in the "acc_mode" flags: uselib already requires MAY_READ for that reason. So you cannot uselib() a non-readable file, unlike execve(). So I think just removing __FMODE_EXEC would just do the RightThing(tm), and changes nothing for any sane situation. In fact, I don't think __FMODE_EXEC really ever did anything for the uselib() case, so removing it *really* shouldn't matter, and only fix the new AppArmor / Tomoyo use. 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. And at least the nfs stuff was about "don't require read permissions for exec", which was already wrong for the uselib() case as per above. So I think the simple oneliner is literally just --- a/fs/exec.c +++ b/fs/exec.c @@ -128,7 +128,7 @@ SYSCALL_DEFINE1(uselib, const char __user *, library) struct filename *tmp = getname(library); int error = PTR_ERR(tmp); static const struct open_flags uselib_flags = { - .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, + .open_flag = O_LARGEFILE | O_RDONLY, .acc_mode = MAY_READ | MAY_EXEC, .intent = LOOKUP_OPEN, .lookup_flags = LOOKUP_FOLLOW, but I obviously have nothing that uses uselib(). I don't see how it really *could* break anything, though, exactly because of that .acc_mode = MAY_READ | MAY_EXEC, that means that the *regular* permission checks already require the file to be readable. Never mind any LSM checks that might be confused. Linus