Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1881519yba; Thu, 25 Apr 2019 07:13:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqziUNzM63F9L02v6sTP4uquDAr378N8PFbDxaEjf/Ta4ccG6lecAOYU4igYJk0M0uqKbohD X-Received: by 2002:a63:2c4c:: with SMTP id s73mr37384217pgs.42.1556201630735; Thu, 25 Apr 2019 07:13:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556201630; cv=none; d=google.com; s=arc-20160816; b=H4gSbeR1ATH4rRnW+64O6qPM+HHr4iqc7hboWsttQI4mVPuQBFHUITs9iRoPFRALVR ERtHV8fFyDtcXMbdEUDnIb3PddNqvoXg2+P8lDu+MITxpEyMhEsXQZsbKIy0pFG44/6v pMfTM7jXQg8mTICyF4fSLHyOsNVA6rV7YYJDuKgRs4DWEnYCXUV8e0OBrJuRiBCn3I9z zhSGx0pwLA2ADdwWOCkO6LF24mDPk4eg8X71/usEWXwxuEYB4e0YjB2PERXdY/RVW39M /gGw0a76cHs4nKFG2m/UgwXr738DwtEXEXAp3mEnfUeHioBf3JxR+KIcmxPevt5XEUy2 oAMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=NBsm3bY5lK4Uw9W4v2L/rjvoiUfVWBCJDqixilb8FdA=; b=1Br5UqUdQwxW3ApX7Rj+Lc9H7fb9tBziaJo0nYzRU5zw/dESnA0L+VgB6aaQ2jDHOD bPEOu+zcYIBUfvA795KLK+g79pbuPJ9vyoVHJvXU3bd6gYuPbCbIg08zAmTk4R9Cl/IX 7v96yl83ggs82MqDu2jtwnUphk5JL8sdNu43GazOQEYpdU+/qpZrmrs6wYxLWgAnJj7W p5Kqi38Q2y1W413pFQu22yUmpKAbsAeI17xz8MgliAC8lIwbqixS/NfpS/NBXXIrRS75 fwgxAUswKN3brZqlwxiWXPRAWgBq2NLF1j0hkY2jmPxFnqTepxGE75zgmBOX5l6N3pKg Gn7A== 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 w21si22021616pgj.513.2019.04.25.07.13.35; Thu, 25 Apr 2019 07:13:50 -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 S1727349AbfDYNZg (ORCPT + 99 others); Thu, 25 Apr 2019 09:25:36 -0400 Received: from tartarus.angband.pl ([54.37.238.230]:36176 "EHLO tartarus.angband.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726120AbfDYNZf (ORCPT ); Thu, 25 Apr 2019 09:25:35 -0400 Received: from kilobyte by tartarus.angband.pl with local (Exim 4.92) (envelope-from ) id 1hJeKv-00077K-W9; Thu, 25 Apr 2019 15:22:49 +0200 Date: Thu, 25 Apr 2019 15:22:49 +0200 From: Adam Borowski To: Aleksa Sarai Cc: Kees Cook , Andy Lutomirski , Al Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , Eric Biederman , Jann Horn , Christian Brauner , David Drysdale , Tycho Andersen , Linux Containers , Linux FS Devel , Linux API , Andrew Morton , Alexei Starovoitov , Chanho Min , Oleg Nesterov , Aleksa Sarai , Linus Torvalds , LKML , linux-arch Subject: Re: [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution Message-ID: <20190425132249.GA26669@angband.pl> References: <20190320143717.2523-1-cyphar@cyphar.com> <20190325130429.dbrgjxnvq3w5cpb3@yavin> <20190424153806.64qkkmkudzodxnz2@yavin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190424153806.64qkkmkudzodxnz2@yavin> X-Junkbait: aaron@angband.pl, zzyx@angband.pl User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: kilobyte@angband.pl X-SA-Exim-Scanned: No (on tartarus.angband.pl); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 25, 2019 at 01:38:06AM +1000, Aleksa Sarai wrote: > * openat(2) ignores unknown flags, meaning that old kernels will ignore > new programs trying to use O_THISROOT and might end up causing > security issues. Yes, it'd be trivial to check whether the new O_* > flags are supported at start-up, but I think a security feature > shouldn't have a foot-gun associated with it. In fact, I didn't know > openat(2) ignored unknown flags until I wrote this patchset -- I > doubt many other userspace developers do either. For this reason, I propose every new syscall that has flags to follow a bitmask scheme, where any flag assigned a bit in the upper half returns EOPNOTSUPP when called on an old kernel. That would allow defining which flags can be safely ignored and which can't. It otherwise takes major hacks to implement a fail-if-not-supported flag while keeping compat with old kernels. For example, for mmap(), MAP_SHARED has been duplicated as MAP_SHARED_VALIDATE just to allow an unrelated flag (MAP_SYNC) to fail on old kernels. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the ⠈⠳⣄⠀⠀⠀⠀ sky. Your cat demands food. The priority should be obvious...