From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DCC7C3A59E for ; Wed, 4 Sep 2019 21:49:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4EC30208E4 for ; Wed, 4 Sep 2019 21:49:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qs65ZKzt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4EC30208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cyphar.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hVb3dWrl2U31J+dNOoeCMeAR5qafsUxBi+5sh7qbPb0=; b=qs65ZKztzsYpDdoQ9d9tG3vX9 9jwdo23cLodtkdYAZEbvTWmMuZgbdVUnCo11pPExj07xzKfgop9iBRQYBdqmjXPgI6Dn8IYcGbMNZ Q7JE7WdVtdyNYeSP1AtKFZw0UzQa8XA66O3b5fm19a+mzfkPHQK6Dtr3VV60UmaHgOyoTG1f5ZHMX 1lmUD6sc5368jec5aZKTioGvHZdzfzG/REyihtX9aJdKQYQDm835VsnpksJt7cBPGou/rS0kFSlim mRxVwksAh8sTB6LV4sMtVeUS7n/9AD2bDh5D46oCpQha0MLUzpwwb658nSZm9vA6VCeFchgOJPx+p QMl93/LHw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i5d9q-0002UV-7a; Wed, 04 Sep 2019 21:49:42 +0000 Received: from mx2.mailbox.org ([80.241.60.215]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1i5d9l-0002SY-Dv for linux-arm-kernel@lists.infradead.org; Wed, 04 Sep 2019 21:49:39 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id D7E89A19C8; Wed, 4 Sep 2019 23:49:24 +0200 (CEST) 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 VdSCaItxf1Ze; Wed, 4 Sep 2019 23:49:19 +0200 (CEST) Date: Thu, 5 Sep 2019 07:48:56 +1000 From: Aleksa Sarai To: Linus Torvalds Subject: Re: [PATCH v12 10/12] namei: aggressively check for nd->root escape on ".." resolution Message-ID: <20190904214856.vnvom7h5xontvngq@yavin.dot.cyphar.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-11-cyphar@cyphar.com> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190904_144937_777306_4EEFCCE9 X-CRM114-Status: GOOD ( 23.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, Linux-sh list , Peter Zijlstra , Rasmus Villemoes , Alexei Starovoitov , Linux List Kernel Mailing , David Howells , "open list:KERNEL SELFTEST FRAMEWORK" , sparclinux@vger.kernel.org, Shuah Khan , linux-arch , linux-s390 , Tycho Andersen , Aleksa Sarai , Jiri Olsa , Alexander Shishkin , Ingo Molnar , Linux ARM , linux-mips@vger.kernel.org, linux-xtensa@linux-xtensa.org, Kees Cook , Arnd Bergmann , Jann Horn , linux-m68k , Al Viro , Andy Lutomirski , Shuah Khan , Namhyung Kim , David Drysdale , Christian Brauner , "J. Bruce Fields" , linux-parisc@vger.kernel.org, Linux API , Chanho Min , Jeff Layton , Oleg Nesterov , Eric Biederman , alpha , linux-fsdevel , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Linux Containers Content-Type: multipart/mixed; boundary="===============4469423287599293669==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4469423287599293669== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="i46h7izteerqaavi" Content-Disposition: inline --i46h7izteerqaavi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-09-04, Linus Torvalds wrote: > On Wed, Sep 4, 2019 at 1:23 PM Aleksa Sarai wrote: > > This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit > > ".." resolution (in the case of LOOKUP_BENEATH the resolution will still > > fail if ".." resolution would resolve a path outside of the root -- > > while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps > > are still disallowed entirely because now they could result in > > inconsistent behaviour if resolution encounters a subsequent ".."[*]. >=20 > This is the only patch in the series that makes me go "umm". >=20 > Why is it ok to re-initialize m_seq, which is used by other things > too? I think it's because we're out of RCU lookup, but there's no > comment about it, and it looks iffy to me. I'd rather have a separate > sequence count that doesn't have two users with different lifetime > rules. Yeah, the reasoning was that it's because we're out of RCU lookup and if we didn't re-grab ->m_seq we'd hit path_is_under() on every subsequent ".." (even though we've checked that it's safe). But yes, I should've used a different field to avoid confusion (and stop it looking unnecessarily dodgy). I will fix that. > But even apart from that, I think from a "patch continuity" standpoint > it would be better to introduce the sequence counts as just an error > condition first - iow, not have the "path_is_under()" check, but just > return -EXDEV if the sequence number doesn't match. Ack, will do. > So you'd have three stages: >=20 > 1) ".." always returns -EXDEV >=20 > 2) ".." returns -EXDEV if there was a concurrent rename/mount >=20 > 3) ".." returns -EXDEV if there was a concurrent rename/mount and we > reset the sequence numbers and check if you escaped. >=20 > becasue the sequence number reset really does make me go "hmm", plus I > get this nagging little feeling in the back of my head that you can > cause nasty O(n^2) lookup cost behavior with deep paths, lots of "..", > and repeated path_is_under() calls. The reason for doing the concurrent-{rename,mount} checks was to try to avoid the O(n^2) in most cases, but you're right that if you have an attacker that is spamming renames (or you're on a box with a lot of renames and/or mounts going on *anywhere*) you will hit an O(n^2) here (more pedantically, O(m*n) but who's counting?). Unfortunately, I'm not sure what the best solution would be for this one. If -EAGAIN retries are on the table, we could limit how many times we're willing to do path_is_under() and then just return -EAGAIN. > So (1) sounds safe. (2) sounds simple. And (3) is where I think subtle > things start happening. >=20 > Also, I'm not 100% convinced that (3) is needed at all. I think the > retry could be done in user space instead, which needs to have a > fallback anyway. Yes? No? Hinting to userspace to do a retry (with -EAGAIN as you mention in your other mail) wouldn't be a bad thing at all, though you'd almost certainly get quite a few spurious -EAGAINs -- &{mount,rename}_lock are global for the entire machine, after all. But if the only significant roadblock is that (3) seems a bit too hairy, I would be quite happy with landing (2) as a first step (with -EAGAIN). --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --i46h7izteerqaavi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXXAxQwAKCRCdlLljIbnQ Er4vAQDiHBfZXElf8shcA4ixj+Uqqylcy09QYhCXLxI7/JHdiQD9GI/Ehs0C3HPA 8HQsyqVEjkx8dq5gApLNG5Rp8gVgywQ= =Il7T -----END PGP SIGNATURE----- --i46h7izteerqaavi-- --===============4469423287599293669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============4469423287599293669==--