From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:33782 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726437AbeLLUmt (ORCPT ); Wed, 12 Dec 2018 15:42:49 -0500 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wBCKXmIF080572 for ; Wed, 12 Dec 2018 15:42:48 -0500 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 2pb7eww8bs-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 12 Dec 2018 15:42:48 -0500 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 12 Dec 2018 20:42:46 -0000 Subject: Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() From: Mimi Zohar To: Jan Kara , =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: linux-kernel@vger.kernel.org, Al Viro , James Morris , Jonathan Corbet , Kees Cook , Matthew Garrett , Michael Kerrisk , =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= , Philippe =?ISO-8859-1?Q?Tr=E9buchet?= , Shuah Khan , Thibaut Sautereau , Vincent Strubel , Yves-Alexis Perez , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, sgrubb@redhat.com, Matthew Bobrowski Date: Wed, 12 Dec 2018 15:42:36 -0500 In-Reply-To: <20181212144306.GA19945@quack2.suse.cz> References: <20181212081712.32347-1-mic@digikod.net> <20181212081712.32347-2-mic@digikod.net> <20181212144306.GA19945@quack2.suse.cz> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1544647356.4028.105.camel@linux.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2018-12-12 at 15:43 +0100, Jan Kara wrote: > > diff --git a/fs/open.c b/fs/open.c > > index 0285ce7dbd51..75479b79a58f 100644 > > --- a/fs/open.c > > +++ b/fs/open.c > > @@ -974,6 +974,10 @@ static inline int build_open_flags(int flags, umode_t mode, struct open_flags *o > > if (flags & O_APPEND) > > acc_mode |= MAY_APPEND; > > > > + /* Check execution permissions on open. */ > > + if (flags & O_MAYEXEC) > > + acc_mode |= MAY_OPENEXEC; > > + > > op->acc_mode = acc_mode; > > > > op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN; > > I don't feel experienced enough in security to tell whether we want this > functionality or not. But if we do this, shouldn't we also set FMODE_EXEC > on the resulting struct file? That way also security_file_open() can be > used to arbitrate such executable opens and in particular > fanotify permission event FAN_OPEN_EXEC will get properly generated which I > guess is desirable (support for it is sitting in my tree waiting for the > merge window) - adding some audit people involved in FAN_OPEN_EXEC to > CC. Just an idea... Assuming the interpreters are properly modified (and signed), MAY_OPENEXEC closes a major IMA measurement/appraisal gap.  The kernel has no insight into the files that the interpreter is opening.  Having the interpreter annotate the file open, allows IMA to differentiate scripts opening data files from code. IMA policy rules could then be written requiring code to be signed. Example IMA policy rules: measure func=FILE_CHECK mask=MAY_OPENEXEC appraise func=FILE_CHECK mask=MAY_OPENEXEC appraise_type=imasig Mimi