linux-kernel - Re: [RFC PATCH v1 0/5] Add support for O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <374ea88c-edc5-f1a6-3637-748635e1e7df@ssi.gouv.fr>
Date:   Thu, 13 Dec 2018 16:17:29 +0100
From:   Mickaël Salaün <mickael.salaun@....gouv.fr>
To:     Matthew Wilcox <willy@...radead.org>,
        Mickaël Salaün <mic@...ikod.net>
CC:     <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 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.