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 D10CDC433EF for ; Mon, 4 Apr 2022 23:02:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233811AbiDDXEj (ORCPT ); Mon, 4 Apr 2022 19:04:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234810AbiDDXEQ (ORCPT ); Mon, 4 Apr 2022 19:04:16 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D1B231370 for ; Mon, 4 Apr 2022 15:25:22 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id w7so10282641pfu.11 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=JBKwUMvVbCG5OJjtFbI4i7Cz4otaDGxptYc/Qx7SFg5Hu+0W1tAJC+ORWeBhWWDIDY K+2AqnneqgKn0lN9z82AvkORG6BBWT3aXA22AZp4nVLM5tYAK2Lu428/lRymHYhzcJcs XY9/Xeedqziql3uGRQEklTI542LwFCYtKVEbD1E44oYg4a2WeYjncKDUR0qgdnbSXGWI OGoSOIN7Zj+Fo+iLFmTc5njPCKA45nQb//OZ6phV/ewpF3ea9izMYNvIFLXOBkJ8gmb/ AUPC3NTHd7KHAnOkZONFrX3dPU2Q6uCvObm9MVQNHiTpIxLb/B1RA50Kq3QNRfEQ9xcs 9TaQ== X-Gm-Message-State: AOAM532c3xSzzPFy9pv2i5Cni1Bqd+Dof9TX43hDnA/dcn8M7eir/xm7 0rIOz5ufscrp0X4ca8wveBr1hw== 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-kernel@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