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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 909A8C433EF for ; Mon, 4 Apr 2022 23:02:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232630AbiDDXEa (ORCPT ); Mon, 4 Apr 2022 19:04:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233001AbiDDXEP (ORCPT ); Mon, 4 Apr 2022 19:04:15 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D72549F8E for ; Mon, 4 Apr 2022 15:25:22 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id s8so10275761pfk.12 for ; Mon, 04 Apr 2022 15:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=gk7YExpjD17yvmNb1YnkwGsNAfvivwtdanWcpr+eU8Y=; b=b4kGzhYdOOBuJA+ydGgqp1rlD/EHbApMFe6NjPa2BcD1b0AjYblro2TW6cHiJwXv1j cIHnWLN+29p+1lVvytOTxUDuVRYGoz8mHzrqWSCMqfa4dNIB3FqIE70xRvHTuuJ9+Prg IMeR3KfPWdMGhvmBnaqnoUY8yhUtgAAzPiOJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=gk7YExpjD17yvmNb1YnkwGsNAfvivwtdanWcpr+eU8Y=; b=IQYnhNM0GfzetYjd7veloQb0F8LCSTNu4smBsVAoEmKznCw2hsCx/2OCecpiCcPYez DUOehDk+9et/5Enqn2t+jBSaYDBks4G6VYv05xE8lN8Y6OQEiicQhjN8YIavUYUpgYZj TFbkUo+4IPu2oAJEpYgl2W8u6IfcftnLeSj9JO0sJ1IEVy3Gs7XAh5+zodFGQ1UK5YPP ONk6c9/N6YnINL9rEBjBFXhTnUm5UjPUZmV+QxxWGfDEM4C7MMI/6LeTldyT7Y9WOVhb /9Q4NVhh3rkPtZPIkhYLoEuNKq/odpbjC/p6IUFoSMAxlmBRh+DDso9gKvri1uqYU6l/ EGQA== X-Gm-Message-State: AOAM532iKWF5E+dH1j8W6W6WlyOFUzrUkTxtwe/ygxsKrzAoOJYCQla0 HFySQ6YYZA0HpDdUDbZcSvUrGg== X-Google-Smtp-Source: ABdhPJxRptxXnfZI/YYw0ccjtfFSL+7+tWY8HL5HqZoAtkFBK4XdlYUkLt5bpzJtf2Kd+v7xUr+vhw== X-Received: by 2002:a62:7b43:0:b0:4fa:6936:6986 with SMTP id w64-20020a627b43000000b004fa69366986mr318150pfc.13.1649111121830; Mon, 04 Apr 2022 15:25:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id q9-20020a056a0002a900b004fde4893cf8sm8710271pfs.200.2022.04.04.15.25.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 15:25:21 -0700 (PDT) Date: Mon, 4 Apr 2022 15:25:19 -0700 From: Kees Cook To: Linus Torvalds Cc: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Al Viro , Andrew Morton , Christian Heimes , Geert Uytterhoeven , James Morris , Luis Chamberlain , Mimi Zohar , Muhammad Usama Anjum , Paul Moore , Philippe =?iso-8859-1?Q?Tr=E9buchet?= , Shuah Khan , Steve Dower , Thibaut Sautereau , Vincent Strubel , linux-fsdevel , linux-integrity , Linux Kernel Mailing List , LSM List , Christian Brauner Subject: Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC) Message-ID: <202204041451.CC4F6BF@keescook> References: <20220321161557.495388-1-mic@digikod.net> <202204041130.F649632@keescook> <816667d8-2a6c-6334-94a4-6127699d4144@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Mon, Apr 04, 2022 at 02:28:19PM -0700, Linus Torvalds wrote: > Now, what I *think* you mean is > > (1) user-space executable loaders want to be able to test the *same* > policy as the kernel does for execve() Right. The script interpreter wants to ask "if this file were actually an ELF going through execve(), would the kernel allow it?" > (2) access(path, EXECVE_OK) will do the same permission checks as > "execve()" would do for that path Maybe. I defer to Mickaël here, but my instinct is to avoid creating an API that can be accidentally misused. I'd like this to be fd-only based, since that removes path name races. (e.g. trusted_for() required an fd.) > (3) if you already have the fd open, use "faccess(fd, NULL, > F_OK_TO_EXECUTE, AT_EMPTY_PATH)" Yes, specifically faccessat2(). (And continuing the race thought above, yes, there could still be races if the content of the file could be changed, but that case is less problematic under real-world conditions.) > (4) maybe we want to add a flag for the "euid vs real uid", and that > would be in the "flags" field, since that changes the actual *lookup* > semantics > > Note that that (4) is something that some normal user space has wanted > in the past too (GNU libcs has a "eaccess()" thing for "effective uid > access"). I think this already exists as AT_EACCESS? It was added with faccessat2() itself, if I'm reading the history correctly. And I just need to say that the thought of setuid script interpreters still makes me sad. :) > - I really want the exact semantics very clearly defined. I think > it's ok to say "exact same security check as for 'execve()'", but even > then we need to have that discussion about > > (a) "what about suid bits that user space cannot react to" What do you mean here? Do you mean setid bits on the file itself? > (b) that whole "effective vs real" discussion I think this is handled with AT_EACCESS? -- Kees Cook