Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1119238imu; Thu, 13 Dec 2018 09:37:33 -0800 (PST) X-Google-Smtp-Source: AFSGD/X+fFBzMVWCVz93w56XJFBqmplSiQJy8XARPIHMzlQvhmdlLeHCuwm9Y7bGK0LV4v5egagg X-Received: by 2002:a17:902:7c85:: with SMTP id y5mr24270724pll.63.1544722653618; Thu, 13 Dec 2018 09:37:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544722653; cv=none; d=google.com; s=arc-20160816; b=FPXful6BaIZ7I4qGkGxp5ByZT5fLQ1QhWIhDE4qgtd9CeAXDVXwpU1WqPAY+q1aYr2 lyex6wPreAObE0S4sI7RNH73BASXz7BZLOjK0loYVqWR7VT5Np1ZrC3G0hZPzXT56izd 31MXAwaIMQ8HXhA+2uSnoYs/6o+CYLJ7x3pbK7Qd5C/8UuHsLbaDFgh5Kf4tZvn6V4Zh g34RKDLnWwG3NTxGplOoRZL+DNP9XnJzI9rx7GyBQ5OoqD3PDosKw0rcC886YhHoeWpg XWgbsrrkx+2Wg8pv4UOKGAhN/YTJIHd9jrTfURtVYnoTpnXxvRZyco+eKkuYukL/BB6K grrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=laKRzsuFdbCVL3lfGBHkWLpa7Tn/EC7u/1vL17/7o6Y=; b=0s6G+NW/SQvzYZLdOtl562ILn4kqkl8VORMj0BP7w9pXvX57ggi3bzniDEHAHnNlEd BjuCa6jNKGSduvFTMzouv85J/bpNxG3LAHvo9p4QDzXiKG39j4gLrQSDN7tN2lXWENrJ E5z5RzoJcXI7f5yMxG1Gp1OndtIYe9qfnHzVCWpSo5PfNnW+/7eslKnWHfgj26Oa3p9O 2iZupXO2ojASGM8A3tqmXWT2SSsPRfaxbRnzKzDzrLcaQ0p9oxyIGZpWR8nEN+3ghPVo /PWWGmxalrD+43NOeU3Ziu8cit8BMnjEwykWpPv2iY6MTo3KlSnAIy6oM3Hvvu9vT2EQ 5yaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ssi.gouv.fr header.s=20160407 header.b=Tgbunuj5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e17si1865020pgj.142.2018.12.13.09.37.18; Thu, 13 Dec 2018 09:37:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ssi.gouv.fr header.s=20160407 header.b=Tgbunuj5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729635AbeLMRgL (ORCPT + 99 others); Thu, 13 Dec 2018 12:36:11 -0500 Received: from smtp-out.ssi.gouv.fr ([86.65.182.90]:64364 "EHLO smtp-out.ssi.gouv.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727775AbeLMRgL (ORCPT ); Thu, 13 Dec 2018 12:36:11 -0500 Received: from smtp-out.ssi.gouv.fr (localhost [127.0.0.1]) by smtp-out.ssi.gouv.fr (Postfix) with ESMTP id 3FFEDD0006C; Thu, 13 Dec 2018 18:36:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ssi.gouv.fr; s=20160407; t=1544722577; bh=RdcVnpRHEidguIx7S5N3aX3ilD93YH7Gi1nPVJMOx9Y=; h=Subject:To:CC:References:From:Date:In-Reply-To:From:Subject; b=Tgbunuj5yfFhYD6pVNhfwWvKI5Xzo8scOQi5hyA3Cwd3TyM3Qauo9DbpO+Qd6pZDx EVz2xNJaVUVrOZ4vlj6d5sorEDl+y6q2VVPybjc6TmdTKTCatpvzale5FLlGnLhMnY H30yHkoraj8ZDeVcG6RZsZpOf0JoQeujdcGNruBNyzOkLXjXmNKEw1kzmLRgbQwqKb cbNmbA1VBVjMURloPxzUhxdlrHaWm8/KE+WJffhhs8r8nduZeJUOI0JrXwglm4pwpX L2zc3NB6Y4X/GrUyebQ5ArMDo72TZgED5K8++XrHy4NAKowNy9EnDBVl+DTLQFUh3T DnnhdaY4xxnPg== Subject: Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC To: Matthew Wilcox CC: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= , , Al Viro , James Morris , Jonathan Corbet , Kees Cook , Matthew Garrett , Michael Kerrisk , Mimi Zohar , =?UTF-8?Q?Philippe_Tr=c3=a9buchet?= , Shuah Khan , Thibaut Sautereau , Vincent Strubel , Yves-Alexis Perez , , , , References: <20181212081712.32347-1-mic@digikod.net> <20181213030228.GM6830@bombadil.infradead.org> <374ea88c-edc5-f1a6-3637-748635e1e7df@ssi.gouv.fr> <20181213171310.GR6830@bombadil.infradead.org> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: Date: Thu, 13 Dec 2018 18:36:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20181213171310.GR6830@bombadil.infradead.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.