Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4490431imm; Mon, 8 Oct 2018 23:53:59 -0700 (PDT) X-Google-Smtp-Source: ACcGV62vhuvQIRgOHzybTzaXgoGvzvt4awDkPXUhF6Fi3WxKEdfpxr43hkE7hzA56FGg92cQD+pz X-Received: by 2002:a62:2606:: with SMTP id m6-v6mr26253094pfm.104.1539068039169; Mon, 08 Oct 2018 23:53:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539068039; cv=none; d=google.com; s=arc-20160816; b=IzB7WoJE2O2nnQhjCsnnb1/LsdRTFX49pHTbbEzUyNDclmD/9GIp9RLs/GYycUNzFT /DadPatmeaCIwZLrA8D3+O23FSj9U9AUeyf33Gz0z3ps3ZsbVKb1dobDREKpne9xW60z GKlpdjpIQhFL/h/+NACfOj/+XQjH9LdRmkOPv+zllZP7l4civIZPnbsMuBvJlbIgMVsb xpRjLyVWgi7WwoXCbRXnYdQVR3SkFF77iGoCdGrGtuQlKBBc19Nwj2qi8UgjIR+ECjAJ dTElFOu8K77m4CNEVxioG9+1zbbV0JnvwemLq7aB5U7KhGWAWmInlAJgmfFnIyE/b4Uz QE/Q== 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:mime-version :message-id:date:subject:cc:to:from; bh=onj4pPDG0YNuHRGPSnTo1+aHaA5RjWQ7fo3wSghyslY=; b=H/d4cZiVBDmmPNwO2yhfTkUBEWDxFisLM5RSt8M6t/Fi4ujfcTy5SqonJnxHyWlvxr f6WUl1MXn4WmIiAfrmWVreHEI4jr3Ia66NSh+aJDo3mDhj2+5BEo4GFC13SwdSgNM6Zn YRm3NitKk2rtbiUtTQE+rABWWXJ5uHimzk+/axjxgocYVE3+MffoVUJgIg5ekA6HuMeR rwkwlXshMjLi58PIUAnqT+IguUKDIlamFtE2ycMLDSRw8TQlo9e0tFoApxePUZo/z/kM X/Kj9hkoZ7F4GmdFfceIWnBlJSznWdhrdp+8DKIyhAlcRpA1eIy6/Cs+Un5mboB2nwEj ggJA== 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 14-v6si16365724pgm.488.2018.10.08.23.53.42; Mon, 08 Oct 2018 23:53:59 -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 S1726415AbeJIOIo (ORCPT + 99 others); Tue, 9 Oct 2018 10:08:44 -0400 Received: from mx1.mailbox.org ([80.241.60.212]:49032 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbeJIOIo (ORCPT ); Tue, 9 Oct 2018 10:08:44 -0400 Received: from smtp1.mailbox.org (unknown [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 592AC4979C; Tue, 9 Oct 2018 08:53:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id S4W4nNWYPnsU; Tue, 9 Oct 2018 08:53:13 +0200 (CEST) From: Aleksa Sarai To: Al Viro , Eric Biederman Cc: Aleksa Sarai , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , Andy Lutomirski , David Howells , Jann Horn , Christian Brauner , Tycho Andersen , David Drysdale , dev@opencontainers.org, containers@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org Subject: [PATCH v2 0/3] namei: implement various lookup restriction AT_* flags Date: Tue, 9 Oct 2018 17:52:56 +1100 Message-Id: <20181009065300.11053-1-cyphar@cyphar.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The need for some sort of control over VFS's path resolution (to avoid malicious paths resulting in inadvertent breakouts) has been a very long-standing desire of many userspace applications. This patchset is a revival of Al Viro's old AT_NO_JUMPS[1,2] patchset (which was a variant of David Drysdale's O_BENEATH patchset[3] which was a spin-off of the capsicum patchset[4]) with a few additions and changes made based on the previous discussion within [5] as well as others I felt were useful. As per the discussion in the AT_NO_JUMPS thread, AT_NO_JUMPS has been split into separate flags. * AT_XDEV blocks mountpoint crossings (both upwards and downwards). openat("/", "tmp", AT_XDEV); // blocked openat("/tmp", "..", AT_XDEV); // blocked openat("/tmp", "/", AT_XDEV); // blocked * AT_NO_PROCLINKS blocks all resolution through /proc/$pid/fd/$fd "symlinks". Specifically, this blocks all jumps caused by a filesystem using nd_jump_link() to shove you around in the filesystem tree (these are referred to as "proclinks" in lieu of a better name). * AT_BENEATH disallows escapes from the starting dirfd using ".." or absolute paths (either in the path or during symlink resolution). Conceptually this flag ensures that you "stay below" the starting point in the filesystem tree. ".." resolution is allowed if it doesn't land you outside of the starting point (this is made safe against races by patch 3 in this series). AT_BENEATH also currently disallows all "proclink" resolution because they can trivially throw you outside of the starting point. In a future patch we might allow such resolution (as long as it stays within the root). In addition, two more flags have been added to the series: * AT_NO_SYMLINKS disallows *all* symlink resolution, and thus implies AT_NO_PROCLINKS. Linus mentioned this is something that git would like to have in the original discussion[5]. * AT_THIS_ROOT is a very similar idea to AT_BENEATH, but it serves a very different purpose. Rather than blocking resolutions if they would go outside of the starting point, it treats the starting point as a form of chroot(2). Container runtimes are one of the primary justifications for this flag, as they currently have to implement this sort of path handling racily in userspace[6]. The restrictions on "proclink" resolution are the same as with AT_BENEATH (though in AT_THIS_ROOT's case it's not really clear how "proclink" jumps outside of the root should be handled), and patch 3 in this series was also required to make ".." resolution safe. Patch changelog: v2: * Made ".." resolution with AT_THIS_ROOT and AT_BENEATH safe by through __d_path checking (see patch 3). * Disallowed "proclinks" with AT_THIS_ROOT and AT_BENEATH, in the hopes they can be re-enabled once safe. * Removed the selftests as they will be reimplemented as xfstests. [1]: https://lwn.net/Articles/721443/ [2]: https://lore.kernel.org/patchwork/patch/784221/ [3]: https://lwn.net/Articles/619151/ [4]: https://lwn.net/Articles/603929/ [5]: https://lwn.net/Articles/723057/ [6]: https://github.com/cyphar/filepath-securejoin Aleksa Sarai (3): namei: implement O_BENEATH-style AT_* flags namei: implement AT_THIS_ROOT chroot-like path resolution namei: aggressively check nd->root on ".." resolution fs/fcntl.c | 2 +- fs/namei.c | 192 ++++++++++++++++++++++--------- fs/open.c | 10 ++ fs/stat.c | 4 +- include/linux/fcntl.h | 3 +- include/linux/namei.h | 8 ++ include/uapi/asm-generic/fcntl.h | 20 ++++ include/uapi/linux/fcntl.h | 10 ++ 8 files changed, 193 insertions(+), 56 deletions(-) -- 2.19.0