[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba523381-1b98-a8bf-ee5b-94a71caee48c@ssi.gouv.fr>
Date: Thu, 13 Dec 2018 18:36:15 +0100
From: Mickaël Salaün <mickael.salaun@....gouv.fr>
To: Matthew Wilcox <willy@...radead.org>
CC: Mickaël Salaün <mic@...ikod.net>,
<linux-kernel@...r.kernel.org>, Al Viro <viro@...iv.linux.org.uk>, James
Morris <jmorris@...ei.org>, Jonathan Corbet <corbet@....net>, Kees Cook
<keescook@...omium.org>, Matthew Garrett <mjg59@...gle.com>, Michael Kerrisk
<mtk.manpages@...il.com>, Mimi Zohar <zohar@...ux.ibm.com>,
Philippe Trébuchet <philippe.trebuchet@....gouv.fr>, Shuah
Khan <shuah@...nel.org>, Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
Vincent Strubel <vincent.strubel@....gouv.fr>, Yves-Alexis Perez
<yves-alexis.perez@....gouv.fr>, <kernel-hardening@...ts.openwall.com>,
<linux-api@...r.kernel.org>, <linux-security-module@...r.kernel.org>,
<linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC
On 13/12/2018 18:13, Matthew Wilcox wrote:
> On Thu, Dec 13, 2018 at 04:17:29PM +0100, Mickaël Salaün wrote:
>> 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
>
> We have somewhat less than 400 syscalls today. We have 20 O_ bits defined.
> Obviously there's a lower practical limit on syscalls, but in principle
> we could have up to 2^32 syscalls, and there are only 12 O_ bits remaining.
>
>> 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.
>
> Ah, but that's the problem. The interpreter can see an -ENOSYS response
> and handle it appropriately. If the flag is silently ignored, the
> interpreter has no idea whether it can do a racy check or whether to
> skip even trying to do the check.
Right, but the interpreter should interpret the script if the open with
O_MAYEXEC succeed (but not otherwise): it may be because the flag is
known by the kernel and the system policy allow this call, or because
the (old) kernel doesn't known about this flag (which is fine and needed
for backward compatibility). The script interpretation must not failed
if the kernel doesn't support O_MAYEXEC, it is then useless for the
interpreter to do any additional check.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
