Message-ID: <382034b9-d9fb-b5d7-5cfe-c78f17abff04@ssi.gouv.fr>
Date:   Mon, 9 Sep 2019 11:33:40 +0200
From:   Mickaël Salaün <mickael.salaun@....gouv.fr>
To:     Andy Lutomirski <luto@...capital.net>,
        Jeff Layton <jlayton@...nel.org>
CC:     Aleksa Sarai <cyphar@...har.com>,
        Florian Weimer <fweimer@...hat.com>,
        Mickaël Salaün <mic@...ikod.net>,
        <linux-kernel@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andy Lutomirski <luto@...nel.org>,
        Christian Heimes <christian@...hon.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Eric Chiang <ericchiang@...gle.com>,
        James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>,
        Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Matthew Garrett <mjg59@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Philippe Trébuchet 
        <philippe.trebuchet@....gouv.fr>,
        Scott Shell <scottsh@...rosoft.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Shuah Khan <shuah@...nel.org>,
        Song Liu <songliubraving@...com>,
        Steve Dower <steve.dower@...hon.org>,
        Steve Grubb <sgrubb@...hat.com>,
        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: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on
 sys_open()


On 06/09/2019 22:06, Andy Lutomirski wrote:
>
>
>> On Sep 6, 2019, at 12:43 PM, Jeff Layton <jlayton@...nel.org> wrote:
>>
>>> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
>>>> On 2019-09-06, Jeff Layton <jlayton@...nel.org> wrote:
>>>>> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>>>>>> On 06/09/2019 17:56, Florian Weimer wrote:
>>>>>> Let's assume I want to add support for this to the glibc dynamic loader,
>>>>>> while still being able to run on older kernels.
>>>>>>
>>>>>> Is it safe to try the open call first, with O_MAYEXEC, and if that fails
>>>>>> with EINVAL, try again without O_MAYEXEC?
>>>>>
>>>>> The kernel ignore unknown open(2) flags, so yes, it is safe even for
>>>>> older kernel to use O_MAYEXEC.
>>>>>
>>>>
>>>> Well...maybe. What about existing programs that are sending down bogus
>>>> open flags? Once you turn this on, they may break...or provide a way to
>>>> circumvent the protections this gives.
>>>
>>> It should be noted that this has been a valid concern for every new O_*
>>> flag introduced (and yet we still introduced new flags, despite the
>>> concern) -- though to be fair, O_TMPFILE actually does have a
>>> work-around with the O_DIRECTORY mask setup.
>>>
>>> The openat2() set adds O_EMPTYPATH -- though in fairness it's also
>>> backwards compatible because empty path strings have always given ENOENT
>>> (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
>>>
>>>> Maybe this should be a new flag that is only usable in the new openat2()
>>>> syscall that's still under discussion? That syscall will enforce that
>>>> all flags are recognized. You presumably wouldn't need the sysctl if you
>>>> went that route too.
>>>
>>> I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
>>> how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
>>> it, since I'd heard about this work through the grape-vine).
>>>
>>
>> I rather like the idea of having openat2 fds be non-executable by
>> default, and having userland request it specifically via O_MAYEXEC (or
>> some similar openat2 flag) if it's needed. Then you could add an
>> UPGRADE_EXEC flag instead?
>>
>> That seems like something reasonable to do with a brand new API, and
>> might be very helpful for preventing certain classes of attacks.
>>
>>
>
> There are at least four concepts of executability here:
>
> - Just check the file mode and any other relevant permissions. Return a normal fd.  Makes sense for script interpreters, perhaps.

This is the purpose of this patch series. It doesn't make sense to add
memory restrictions nor constrain fexecve and such.


>
> - Make the fd fexecve-able.
>
> - Make the resulting fd mappable PROT_EXEC.
>
> - Make the resulting fd upgradable.
>
> I’m not at all convinced that the kernel needs to distinguish all these, but at least upgradability should be its own thing IMO.
>

--
Mickaël Salaün

Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@...sn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@...sn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

Powered by blists - more mailing lists