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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3BC6C43461 for ; Tue, 8 Sep 2020 19:59:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B8B2820658 for ; Tue, 8 Sep 2020 19:59:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eTCVIzNm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732609AbgIHT7i (ORCPT ); Tue, 8 Sep 2020 15:59:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730361AbgIHPfh (ORCPT ); Tue, 8 Sep 2020 11:35:37 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67B39C06137A; Tue, 8 Sep 2020 05:52:13 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id e23so14728383otk.7; Tue, 08 Sep 2020 05:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RSBroElt/2rd8PC1JxxbAAzGUdGD8+TpQ3WZUmiUhpM=; b=eTCVIzNm1ErwySELQBxnMmM/AgczXHFoHr7tAYK0AzvrrFpGaltdTw3BU3s6nbzZwV FVze43SwEAqT9SvAQmGOzyCxUMdZtymO/iomH+o46b3/yM0Ox9AJ3+9Xn2WMnWTK0Bc3 M2VQ+2ueKbAh3cxEBdKEnnfwm2WR+1pf/wzXaClR2OEX+s2dpP4cdruEpT01B2oKaCgT WAyhBPyfgKh1zK7exA8S4xxepCiPC2CX0rFJd9/j1ZBlLdrkBQj4c0Vf0Iq6RPftxU89 +cgdAfBDF5x1mUuE2nCFjBhzD7FADAqHMbVgOC1KJQAzh/bpLmx1qjElc/fALXBLVFU9 hajQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RSBroElt/2rd8PC1JxxbAAzGUdGD8+TpQ3WZUmiUhpM=; b=HFCoLr3qa9KDqPLImsrK5qzR1iAcNcPCAC7iJW+sUuZKhrNU30zAawR0ITu1l9roWg eeErUaO0N153M5A5Y6e+v+koUbdB/fA0uouRJmuqH/VGhsADfswBWdHK7bl9T7mEvkNZ g+98ADvbpVjyZ4oJ8Uah9RywW+JI8+rZ9mAtS2/vy3LtCBWwxnxaV48vErY7+a341/Zx MYhTZhMLDKAnPLE96izXi2+yJl9UwFO4qIS+KE5W+Hmr96TewKWvO53gvihMTyBvTC3h dRoSWmjQ6PgiBiPFzFSWcw4IUlWYnHzcL772sEDxQDYW5gny5JENu07g3lHWPImiDYPS p8Rg== X-Gm-Message-State: AOAM5339VplX8qn2Hc0nCIcXHEY3b8S/pJgpnYA/PdIhGGeQkNVoCUJq ki7oS8H/LSWv73cFY0RNq7FV8IFZ2DHy2ZPR7Ik= X-Google-Smtp-Source: ABdhPJxkV3KPZWICtf1txHSRVep4rHIt7AdIIVwPHFJWR6ocRJEX5qRfN+Lfgk+mF/ZkzhvREH+BKcYfiF/pqjxb3rI= X-Received: by 2002:a9d:7a92:: with SMTP id l18mr16914681otn.89.1599569532734; Tue, 08 Sep 2020 05:52:12 -0700 (PDT) MIME-Version: 1.0 References: <20200908075956.1069018-1-mic@digikod.net> <20200908075956.1069018-2-mic@digikod.net> <75451684-58f3-b946-dca4-4760fa0d7440@digikod.net> In-Reply-To: From: Stephen Smalley Date: Tue, 8 Sep 2020 08:52:01 -0400 Message-ID: Subject: Re: [RFC PATCH v8 1/3] fs: Introduce AT_INTERPRETED flag for faccessat2(2) To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Mimi Zohar , linux-kernel , Aleksa Sarai , Alexei Starovoitov , Al Viro , Andrew Morton , Andy Lutomirski , Christian Brauner , Christian Heimes , Daniel Borkmann , Deven Bowers , Dmitry Vyukov , Eric Biggers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , Miklos Szeredi , =?UTF-8?Q?Philippe_Tr=C3=A9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Tetsuo Handa , Thibaut Sautereau , Vincent Strubel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-integrity@vger.kernel.org, LSM List , Linux FS Devel , Thibaut Sautereau , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , John Johansen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 8, 2020 at 8:50 AM Stephen Smalley wrote: > > On Tue, Sep 8, 2020 at 8:43 AM Micka=C3=ABl Sala=C3=BCn = wrote: > > > > > > On 08/09/2020 14:28, Mimi Zohar wrote: > > > Hi Mickael, > > > > > > On Tue, 2020-09-08 at 09:59 +0200, Micka=C3=ABl Sala=C3=BCn wrote: > > >> + mode |=3D MAY_INTERPRETED_EXEC; > > >> + /* > > >> + * For compatibility reasons, if the system-wid= e policy > > >> + * doesn't enforce file permission checks, then > > >> + * replaces the execute permission request with= a read > > >> + * permission request. > > >> + */ > > >> + mode &=3D ~MAY_EXEC; > > >> + /* To be executed *by* user space, files must b= e readable. */ > > >> + mode |=3D MAY_READ; > > > > > > After this change, I'm wondering if it makes sense to add a call to > > > security_file_permission(). IMA doesn't currently define it, but > > > could. > > > > Yes, that's the idea. We could replace the following inode_permission() > > with file_permission(). I'm not sure how this will impact other LSMs th= ough. > > They are not equivalent at least as far as SELinux is concerned. > security_file_permission() was only to be used to revalidate > read/write permissions previously checked at file open to support > policy changes and file or process label changes. We'd have to modify > the SELinux hook if we wanted to have it check execute access even if > nothing has changed since open time. Also Smack doesn't appear to implement file_permission at all, so it would skip Smack checking.