Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4934905ybe; Mon, 9 Sep 2019 17:38:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1+mYJkDutjQBdWC8uDApGUCVsQal05k6E+aRfUYso6Dr3GD2yEhsZXEOhL6OxtZQyV+qw X-Received: by 2002:a05:6402:347:: with SMTP id r7mr27282801edw.41.1568075895504; Mon, 09 Sep 2019 17:38:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568075895; cv=none; d=google.com; s=arc-20160816; b=kFLJWD1Q4qvETZRpC0J5IJQ5tsdHmcEcKdWX6yqN3Xt2VofLFZDXF9LAsCnaur3Atg 3fEe3RoC06tPhKaiI7fsrPn+nSU94v2yuI8SIckIwVS6Igl2DaroUKhpjzOzPAVn1mVQ fzsGFoyDXZvxPfjkjbSJNAq6RQs6vZoz4eIR6z5o9s6B+vi7kMFFXPVc+cOIfNWssOWL D/OdeLRaHfYMPhitJZHncvTtNLnTyVomwADVDaK+LHjmBy0rFaZOpEmV6bdkZUCdchDJ pvjNAjnuvThk2Cr1kv3jRS+1Cq/NN1QYwyQWHG9eMGktU2BHIARrKz+L/gD1X29T96hb /r7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=aK4MV07D6Z9hTOlcdM8+GoPgglWcE5iWsntTGTmFodg=; b=gJlnLM5lFHmLowvqYRW7RdIA5exGZnpkxdkmro+PLoyjlZEKt2BCHHLWXC/LTerp4+ tZEVllW6Ov69J+PTxhN6orgNoksz6l/wMx7W/uCHozgxLXcwKMqmmohy4hYTC4528Zxg ZR0XAFUKZwuGyE3DJGYXVP3d6V3UCKBaW4TabnkhxuLzgO3gzwn9+4lw51bFfzWHKifV HrQnyB7WQQyM9r0cHwYisGIn0ds+2uJOOiILrejYAjXhQ4Q0UpVw0rlbYEPqvJbXJuvv 9eA98vHO51WRb2o6vgH4nFTIxSFFOIcCZMqyPf5EzYomK+Ve6g9l8AaOcG3OwEQ+vWv8 s+IA== ARC-Authentication-Results: i=1; mx.google.com; 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 y47si10426792edd.236.2019.09.09.17.37.50; Mon, 09 Sep 2019 17:38:15 -0700 (PDT) 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; 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 S2404515AbfIILy5 (ORCPT + 99 others); Mon, 9 Sep 2019 07:54:57 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:34966 "EHLO mx2.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730901AbfIILy4 (ORCPT ); Mon, 9 Sep 2019 07:54:56 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id BAB3BA01CD; Mon, 9 Sep 2019 13:54:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id v88C_yIZE0OA; Mon, 9 Sep 2019 13:54:46 +0200 (CEST) Date: Mon, 9 Sep 2019 21:54:37 +1000 From: Aleksa Sarai To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: James Morris , Jeff Layton , Florian Weimer , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , linux-kernel@vger.kernel.org, Alexei Starovoitov , Al Viro , Andy Lutomirski , Christian Heimes , Daniel Borkmann , Eric Chiang , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , Mimi Zohar , Philippe =?utf-8?Q?Tr=C3=A9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Song Liu , Steve Dower , Steve Grubb , Thibaut Sautereau , Vincent Strubel , Yves-Alexis Perez , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Message-ID: <20190909115437.jwpyslcdhhvzo7g5@yavin> References: <20190906152455.22757-1-mic@digikod.net> <20190906152455.22757-2-mic@digikod.net> <87ef0te7v3.fsf@oldenburg2.str.redhat.com> <75442f3b-a3d8-12db-579a-2c5983426b4d@ssi.gouv.fr> <1fbf54f6-7597-3633-a76c-11c4b2481add@ssi.gouv.fr> <5a59b309f9d0603d8481a483e16b5d12ecb77540.camel@kernel.org> <49e98ece-e85f-3006-159b-2e04ba67019e@ssi.gouv.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ez37ojmvznisdz5u" Content-Disposition: inline In-Reply-To: <49e98ece-e85f-3006-159b-2e04ba67019e@ssi.gouv.fr> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ez37ojmvznisdz5u Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-09, Micka=EBl Sala=FCn wrote: > On 06/09/2019 21:03, James Morris wrote: > > On Fri, 6 Sep 2019, Jeff Layton wrote: > > > >> The fact that open and openat didn't vet unknown flags is really a bug. > >> > >> Too late to fix it now, of course, and as Aleksa points out, we've > >> worked around that in the past. Now though, we have a new openat2 > >> syscall on the horizon. There's little need to continue these sorts of > >> hacks. > >> > >> New open flags really have no place in the old syscalls, IMO. > > > > Agree here. It's unfortunate but a reality and Linus will reject any su= ch > > changes which break existing userspace. >=20 > Do you mean that adding new flags to open(2) is not possible? It is possible, as long as there is no case where a program that works today (and passes garbage to the unused bits in flags) works with the change. O_TMPFILE was okay because it's actually two flags (one is O_DIRECTORY) and no working program does file IO to a directory (there are also some other tricky things done there, I'll admit I don't fully understand it). O_EMPTYPATH works because it's a no-op with non-empty path strings, and empty path strings have always given an error (so no working program does it today). However, O_MAYEXEC will result in programs that pass garbage bits to potentially get -EACCES that worked previously. > As I said, O_MAYEXEC should be ignored if it is not supported by the > kernel, which perfectly fit with the current open(2) flags behavior, and > should also behave the same with openat2(2). NACK on having that behaviour with openat2(2). -EINVAL on unknown flags is how all other syscalls work (any new syscall proposed today that didn't do that would be rightly rejected), and is a quirk of open(2) which unfortunately cannot be fixed. The fact that *every new O_ flag needs to work around this problem* should be an indication that this interface mis-design should not be allowed to infect any more syscalls. Note that this point is regardless of the fact that O_MAYEXEC is a *security* flag -- if userspace wants to have a secure fallback on old kernels (which is "the right thing" to do) they would have to do more work than necessary. And programs that don't care don't have to do anything special. However with -EINVAL, the programs doing "the right thing" get an easy -EINVAL check. And programs that don't care can just un-set O_MAYEXEC and retry. You should be forced to deal with the case where a flag is not supported -- and this is doubly true of security flags! --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --ez37ojmvznisdz5u Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXY9egAKCRCdlLljIbnQ EjqNAQDvCWENjLmSU64mc7qWEe/HYDu0pcFBvD0dJVUnIZyr0QD/dtKaeEjccIWh RCZTPOrv97U5RjHt3IPWeWSeHVLCcAo= =tOAG -----END PGP SIGNATURE----- --ez37ojmvznisdz5u--