LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: "Jan Kara" <jack@suse.cz>, "Mickaël Salaün" <mic@digikod.net>
Cc: linux-kernel@vger.kernel.org, "Al Viro" <viro@zeniv.linux.org.uk>,
	"James Morris" <jmorris@namei.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Kees Cook" <keescook@chromium.org>,
	"Matthew Garrett" <mjg59@google.com>,
	"Michael Kerrisk" <mtk.manpages@gmail.com>,
	"Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>,
	"Philippe Trébuchet" <philippe.trebuchet@ssi.gouv.fr>,
	"Shuah Khan" <shuah@kernel.org>,
	"Thibaut Sautereau" <thibaut.sautereau@ssi.gouv.fr>,
	"Vincent Strubel" <vincent.strubel@ssi.gouv.fr>,
	"Yves-Alexis Perez" <yves-alexis.perez@ssi.gouv.fr>,
	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" <mbobrowski@mbobrowski.org>
Subject: Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
Date: Wed, 12 Dec 2018 15:42:36 -0500
Message-ID: <1544647356.4028.105.camel@linux.ibm.com> (raw)
In-Reply-To: <20181212144306.GA19945@quack2.suse.cz>

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


  parent reply index

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12  8:17 [RFC PATCH v1 0/5] Add support for O_MAYEXEC Mickaël Salaün
2018-12-12  8:17 ` [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün
2018-12-12 14:43   ` Jan Kara
2018-12-12 17:09     ` Mickaël Salaün
2018-12-12 20:42     ` Mimi Zohar [this message]
2018-12-13  9:47     ` Matthew Bobrowski
2018-12-13 14:23       ` Mickaël Salaün
2019-04-15 18:47     ` Steve Grubb
2019-04-16 11:49       ` Florian Weimer
2019-04-16 15:34         ` Steve Grubb
2019-04-17 10:01           ` Florian Weimer
2019-04-17 15:04             ` Mickaël Salaün
2019-04-17 14:55       ` Mickaël Salaün
2019-08-04 23:55     ` Andy Lutomirski
2019-08-06 16:40       ` Mickaël Salaün
2018-12-12  8:17 ` [RFC PATCH v1 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie Mickaël Salaün
2018-12-12  8:17 ` [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC Mickaël Salaün
2018-12-12 14:28   ` Mickaël Salaün
2018-12-12 17:09   ` Jann Horn
2018-12-13 14:49     ` Mickaël Salaün
2019-01-03 11:17       ` Jann Horn
2019-01-08 13:29         ` Mickaël Salaün
2019-01-08 23:30           ` Kees Cook
2019-01-09 13:41             ` Mickaël Salaün
2018-12-12  8:17 ` [RFC PATCH v1 4/5] selftest/yama: Add tests for O_MAYEXEC enforcing Mickaël Salaün
2018-12-12  8:17 ` [RFC PATCH v1 5/5] doc: Add documentation for Yama's open_mayexec_enforce Mickaël Salaün
2018-12-12 16:29 ` [RFC PATCH v1 0/5] Add support for O_MAYEXEC Jordan Glover
2018-12-12 17:01   ` Mickaël Salaün
2018-12-12 19:51 ` James Morris
2018-12-12 20:13   ` Florian Weimer
2018-12-12 23:40     ` James Morris
2018-12-13  5:13       ` Florian Weimer
2018-12-13 14:57         ` Mickaël Salaün
2018-12-13  3:02 ` Matthew Wilcox
2018-12-13  5:22   ` Florian Weimer
2018-12-13 11:04   ` Mimi Zohar
2018-12-13 11:26     ` Florian Weimer
2018-12-13 12:16       ` Mimi Zohar
2018-12-13 12:16     ` Matthew Wilcox
2018-12-13 15:17   ` Mickaël Salaün
2018-12-13 17:13     ` Matthew Wilcox
2018-12-13 17:36       ` Mickaël Salaün
2018-12-13 17:44         ` Matthew Wilcox

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1544647356.4028.105.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=corbet@lwn.net \
    --cc=jack@suse.cz \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=mic@digikod.net \
    --cc=mickael.salaun@ssi.gouv.fr \
    --cc=mjg59@google.com \
    --cc=mtk.manpages@gmail.com \
    --cc=philippe.trebuchet@ssi.gouv.fr \
    --cc=sgrubb@redhat.com \
    --cc=shuah@kernel.org \
    --cc=thibaut.sautereau@ssi.gouv.fr \
    --cc=vincent.strubel@ssi.gouv.fr \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yves-alexis.perez@ssi.gouv.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox