Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp627987img; Wed, 20 Mar 2019 07:41:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqzQtik0ahoUDmpZvYxP8vHaj6b4CgSO+8EyRDxYxf7tHLC8gC+I3YOpS4jn6ut7mkzlVKIE X-Received: by 2002:a17:902:b481:: with SMTP id y1mr5201225plr.338.1553092864673; Wed, 20 Mar 2019 07:41:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553092864; cv=none; d=google.com; s=arc-20160816; b=FWJS+WHwv+V0Qxu04Bwt1iqu/m9TvrVCvIgPwQw1/hj+qRdjqxES2p0eLhiLjFYU70 /lG0dB1MB/dc3VSIpAM6b5fpDnGSmzMAFmN5etO6+VOX3uqCvK6zHGCZRyDhQhZL46lt BKp8zA+e4XNzXkvCZyRY6JA2ku5Eate/BsKCq67+EuKopFywlT0EXJGVSqCBAfaZkeXQ rZ7eAds+IePyJdNgPPHKemjQ+d/blWegVnzhsQHA133dsl+/buJMHg5CyIuptKHnNgLs 7oUfIX0ztZhQZMn42PqA7zpKecqC/yOJO6TPbA0EoFjUGOfmhPIggB+Qxo4Le5AKp4HQ 89JA== 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=92dtef83RQ5wu8+aADbqO97nzIwNwJYokC49V4Xw3p0=; b=amtV6n+v0AgJG0Ca7OMAeFzW4CEzBF7WExroKozq64h11wxip1r130rnxbNQAtaFFk jQtB6WCOM1zmtmKX2wGI/KyNrP8AMkr5btb8JhZLiyJU3nFQUoroEO67T1U0o2Zt6PNT psEfnni7NAePqfV0iwRdrTHhjtyE4JVrqTfGUiYNZuxG8CuJRJgWrqmCd1JyDFgYME03 FlsXK5RWZvXtVPXq0bqwZ6WCFenhJds7qKKQBEboWCMRF7QeZzxDh6ws3J1+HpEO18Z0 dkAuOHrDDSX4DCs1tMqatbFrwqPpuFYfMAz2XQGBhJg2ZPZ7Q3bwcp2JBq60vcuUpjo+ wsUQ== 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 q11si2009225plr.379.2019.03.20.07.40.49; Wed, 20 Mar 2019 07:41:04 -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 S1727942AbfCTOiG (ORCPT + 99 others); Wed, 20 Mar 2019 10:38:06 -0400 Received: from mx1.mailbox.org ([80.241.60.212]:49408 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726067AbfCTOiF (ORCPT ); Wed, 20 Mar 2019 10:38:05 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 910874DB60; Wed, 20 Mar 2019 15:38:00 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id e8P2zbHU0YLS; Wed, 20 Mar 2019 15:37:47 +0100 (CET) From: Aleksa Sarai To: Al Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells Cc: Aleksa Sarai , Eric Biederman , Andy Lutomirski , Jann Horn , Christian Brauner , David Drysdale , Tycho Andersen , Kees Cook , containers@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, Andrew Morton , Alexei Starovoitov , Chanho Min , Oleg Nesterov , Aleksa Sarai , Linus Torvalds , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution Date: Thu, 21 Mar 2019 01:37:12 +1100 Message-Id: <20190320143717.2523-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 Now that the holiday break is over, it's time to re-send this patch series (with a few additions, due to new information we got from CVE-2019-5736 -- which this patchset mostly protected against but had some holes with regards to #!-style scripts). Patch changelog: v5: * In response to CVE-2019-5736 (one of the vectors showed that open(2)+fexec(3) cannot be used to scope binfmt_script's implicit open_exec()), AT_* flags have been re-added and are now piped through to binfmt_script (and other binfmt_* that use open_exec) but are only supported for execveat(2) for now. v4: * Remove AT_* flag reservations, as they require more discussion. * Switch to path_is_under() over __d_path() for breakout checking. * Make O_XDEV no longer block openat("/tmp", "/", O_XDEV) -- dirfd is now ignored for absolute paths to match other flags. * Improve the dirfd_path_init() refactor and move it to a separate commit. * Remove reference to Linux-capsicum. * Switch "proclink" name to "magic link". v3: [resend] v2: * Made ".." resolution with AT_THIS_ROOT and AT_BENEATH safe(r) with some semi-aggressive __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. * Removed stat(2) support, since you can already get it through O_PATH and fstatat(2). 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 project[4]) with a few additions and changes made based on the previous discussion within [5] as well as others I felt were useful. In line with the conclusions of the original discussion of AT_NO_JUMPS, the flag has been split up into separate flags: * O_XDEV blocks all mountpoint crossings (upwards, downwards, or through absolute links). Absolute pathnames alone in openat(2) do not trigger this. * O_NOMAGICLINKS blocks resolution through /proc/$pid/fd-style links. This is done by blocking the usage of nd_jump_link() during resolution in a filesystem. The term "magic links" is used to match with the only reference to these links in Documentation/, but I'm happy to change the name. It should be noted that this is different to the scope of O_NOFOLLOW in that it applies to all path components. However, you can do open(O_NOFOLLOW|O_NOMAGICLINKS|O_PATH) on a "magic link" and it will *not* fail (assuming that no parent component was a "magic link"), and you will have an fd for the "magic link". * O_BENEATH disallows escapes to outside the starting dirfd's tree, using techniques such as ".." or absolute links. Absolute paths in openat(2) are also disallowed. Conceptually this flag is to ensure you "stay below" a certain point in the filesystem tree -- but this requires some additional to protect against various races that would allow escape using ".." (see patch 4 for more detail). Currently O_BENEATH implies O_NOMAGICLINKS, because it can trivially beam you around the filesystem (breaking the protection). In future, there might be similar safety checks as in patch 4, but that requires more discussion. In addition, two new flags were added that expand on the above ideas: * O_NOSYMLINKS does what it says on the tin. No symlink resolution is allowed at all, including "magic links". Just as with O_NOMAGICLINKS this can still be used with (O_PATH|O_NOFOLLOW) to open an fd for the symlink as long as no parent path had a symlink component. * O_THISROOT is an extension of O_BENEATH that, rather than blocking attempts to move past the root, forces all such movements to be scoped to the starting point. This provides chroot(2)-like protection but without the cost of a chroot(2) for each filesystem operation, as well as being safe against race attacks that chroot(2) is not. If a race is detected (as with O_BENEATH) then an error is generated, and similar to O_BENEATH it is not permitted to cross "magic links" with O_THISROOT. The primary need for this is from container runtimes, which currently need to do symlink scoping in userspace[6] when opening paths in a potentially malicious container. There is a long list of CVEs that could have bene mitigated by having O_THISROOT (such as CVE-2017-1002101, CVE-2017-1002102, CVE-2018-15664, and CVE-2019-5736, just to name a few). In addition, a mirror set of AT_* flags have been added (though currently these are only supported for execveat(2) -- and not for any other syscall). The need for these is explained in the final patch in the series (it's motivated by CVE-2019-5736). Cc: Al Viro Cc: Eric Biederman Cc: Andy Lutomirski Cc: David Howells Cc: Jann Horn Cc: Christian Brauner Cc: David Drysdale Cc: Tycho Andersen Cc: Kees Cook Cc: Cc: Cc: [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 (5): namei: split out nd->dfd handling to dirfd_path_init namei: O_BENEATH-style path resolution flags namei: O_THISROOT: chroot-like path resolution namei: aggressively check for nd->root escape on ".." resolution binfmt_*: scope path resolution of interpreters fs/binfmt_elf.c | 2 +- fs/binfmt_elf_fdpic.c | 2 +- fs/binfmt_em86.c | 4 +- fs/binfmt_misc.c | 2 +- fs/binfmt_script.c | 2 +- fs/exec.c | 26 +++- fs/fcntl.c | 2 +- fs/namei.c | 205 ++++++++++++++++++++++--------- fs/open.c | 13 +- include/linux/binfmts.h | 1 + include/linux/fcntl.h | 3 +- include/linux/fs.h | 9 +- include/linux/namei.h | 8 ++ include/uapi/asm-generic/fcntl.h | 17 +++ include/uapi/linux/fcntl.h | 6 + 15 files changed, 228 insertions(+), 74 deletions(-) -- 2.21.0