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=-5.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 6621BC43461 for ; Tue, 8 Sep 2020 13:30:19 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 5233623C2D for ; Tue, 8 Sep 2020 13:30:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="nX/01NNx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5233623C2D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-19807-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 5283 invoked by uid 550); 8 Sep 2020 13:30:10 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 5257 invoked from network); 8 Sep 2020 13:30:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=jfLTOkb0DRyPqo4i4l2p3Sh7Mx8d6J0Yw6pAMOu9mVM=; b=nX/01NNxaa92Rl1Ego8qtBlBABFCgR8pOwh/ocMM0ry65QsBwr2XWMKftfg/am870VDp stVQ3SJxUP3f6yOobHXoROZmOPZAvEQ6eFZCX9AgIAwavmUq8wRdG5qn3QfY9MxB+8iI CV3QaH/gqz2IziqKcP7slNrUzQzCGepZgpp2yrOmLHAswCGz2GaNMVT/QcoXRUSj0vAV tuzek9sNCkYWH1LaSxRy8y3Qdx5QkMu3KE1RYbN7lVXw3Z1GGE1rYEKHuzmYJTsfZZ4k mj83KsuWDs7Reu1Y7W6uYU9Xf5amXHRNHilE6HXSRIColM6/3hHZbqX+srzr30PqAaUm fQ== Message-ID: Subject: Re: [RFC PATCH v8 1/3] fs: Introduce AT_INTERPRETED flag for faccessat2(2) From: Mimi Zohar To: Stephen Smalley , =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: 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 , Philippe =?ISO-8859-1?Q?Tr=E9buchet?= , 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 , =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= , John Johansen Date: Tue, 08 Sep 2020 09:29:10 -0400 In-Reply-To: References: <20200908075956.1069018-1-mic@digikod.net> <20200908075956.1069018-2-mic@digikod.net> <75451684-58f3-b946-dca4-4760fa0d7440@digikod.net> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.28.5 (3.28.5-12.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-08_06:2020-09-08,2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 phishscore=0 impostorscore=0 mlxscore=0 mlxlogscore=866 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080123 On Tue, 2020-09-08 at 08:52 -0400, Stephen Smalley wrote: > On Tue, Sep 8, 2020 at 8:50 AM Stephen Smalley > wrote: > > > > On Tue, Sep 8, 2020 at 8:43 AM Mickaël Salaün wrote: > > > > > > > > > On 08/09/2020 14:28, Mimi Zohar wrote: > > > > Hi Mickael, > > > > > > > > On Tue, 2020-09-08 at 09:59 +0200, Mickaël Salaün wrote: > > > >> + mode |= MAY_INTERPRETED_EXEC; > > > >> + /* > > > >> + * For compatibility reasons, if the system-wide policy > > > >> + * doesn't enforce file permission checks, then > > > >> + * replaces the execute permission request with a read > > > >> + * permission request. > > > >> + */ > > > >> + mode &= ~MAY_EXEC; > > > >> + /* To be executed *by* user space, files must be readable. */ > > > >> + mode |= 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 though. I wasn't suggesting replacing the existing security_inode_permission hook later, but adding a new security_file_permission hook here. > > > > 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. My question is whether adding a new security_file_permission call here would break either SELinux or Apparmor? Mimi