From: "Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>
To: "Matthew Wilcox" <willy@infradead.org>,
"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>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"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
Subject: Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
Date: Thu, 13 Dec 2018 16:17:29 +0100 [thread overview]
Message-ID: <374ea88c-edc5-f1a6-3637-748635e1e7df@ssi.gouv.fr> (raw)
In-Reply-To: <20181213030228.GM6830@bombadil.infradead.org>
On 13/12/2018 04:02, Matthew Wilcox wrote:
> On Wed, Dec 12, 2018 at 09:17:07AM +0100, Mickaël Salaün wrote:
>> The goal of this patch series is to control script interpretation. A
>> new O_MAYEXEC flag used by sys_open() is added to enable userland script
>> interpreter to delegate to the kernel (and thus the system security
>> policy) the permission to interpret scripts or other files containing
>> what can be seen as commands.
>
> I don't have a problem with the concept, but we're running low on O_ bits.
> Does this have to be done before the process gets a file descriptor,
> or could we have a new syscall? Since we're going to be changing the
> interpreters anyway, it doesn't seem like too much of an imposition to
> ask them to use:
>
> int verify_for_exec(int fd)
>
> instead of adding an O_MAYEXEC.
>
Adding a new syscall for this simple use case seems excessive. I think
that the open/openat syscall familly are the right place to do an atomic
open and permission check, the same way the kernel does for other file
access. Moreover, it will be easier to patch upstream interpreters
without the burden of handling a (new) syscall that may not exist on the
running system, whereas unknown open flags are ignored.
next prev parent reply other threads:[~2018-12-13 15:17 UTC|newest]
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
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 [this message]
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 publicly 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=374ea88c-edc5-f1a6-3637-748635e1e7df@ssi.gouv.fr \
--to=mickael.salaun@ssi.gouv.fr \
--cc=corbet@lwn.net \
--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=mic@digikod.net \
--cc=mjg59@google.com \
--cc=mtk.manpages@gmail.com \
--cc=philippe.trebuchet@ssi.gouv.fr \
--cc=shuah@kernel.org \
--cc=thibaut.sautereau@ssi.gouv.fr \
--cc=vincent.strubel@ssi.gouv.fr \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=yves-alexis.perez@ssi.gouv.fr \
--cc=zohar@linux.ibm.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).