From patchwork Fri Jul 24 20:39:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 6862811 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id F31B9C05AC for ; Fri, 24 Jul 2015 20:45:44 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0864220588 for ; Fri, 24 Jul 2015 20:45:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 72BA820582 for ; Fri, 24 Jul 2015 20:45:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754107AbbGXUpl (ORCPT ); Fri, 24 Jul 2015 16:45:41 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:32834 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753030AbbGXUpk (ORCPT ); Fri, 24 Jul 2015 16:45:40 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZIjqZ-0005z9-9g; Fri, 24 Jul 2015 14:45:35 -0600 Received: from 97-119-29-57.omah.qwest.net ([97.119.29.57] helo=x220.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZIjqY-0004i8-0F; Fri, 24 Jul 2015 14:45:35 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Miklos Szeredi Cc: Linux Containers , linux-fsdevel , Al Viro , Andy Lutomirski , "Serge E. Hallyn" , Richard Weinberger , Andrey Vagin , Jann Horn , Willy Tarreau , Omar Sandoval References: <871tncuaf6.fsf@x220.int.ebiederm.org> <87mw5xq7lt.fsf@x220.int.ebiederm.org> <87a8yqou41.fsf_-_@x220.int.ebiederm.org> <874moq9oyb.fsf_-_@x220.int.ebiederm.org> Date: Fri, 24 Jul 2015 15:39:02 -0500 In-Reply-To: (Miklos Szeredi's message of "Mon, 13 Apr 2015 14:18:40 +0200") Message-ID: <87wpxp70k9.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-XM-AID: U2FsdGVkX1/Bjo6SG3vvjAeOd2QnSJgin2x+10P5Y3g= X-SA-Exim-Connect-IP: 97.119.29.57 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Miklos Szeredi X-Spam-Relay-Country: X-Spam-Timing: total 743 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.7 (0.6%), b_tie_ro: 3.3 (0.4%), parse: 1.24 (0.2%), extract_message_metadata: 19 (2.6%), get_uri_detail_list: 2.9 (0.4%), tests_pri_-1000: 6 (0.9%), tests_pri_-950: 1.15 (0.2%), tests_pri_-900: 0.94 (0.1%), tests_pri_-400: 28 (3.7%), check_bayes: 26 (3.5%), b_tokenize: 7 (0.9%), b_tok_get_all: 9 (1.3%), b_comp_prob: 3.2 (0.4%), b_tok_touch_all: 4.0 (0.5%), b_finish: 0.98 (0.1%), tests_pri_0: 672 (90.5%), tests_pri_500: 6 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH review 0/4] Loopback mount escape fixes X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Miklos Szeredi writes: > On Thu, Apr 9, 2015 at 1:31 AM, Eric W. Biederman wrote: >> >> After the last round of feedback I sat down and played with my fix >> for the fact that a strategically placed rename, ".." on bind mounts >> go up past the root of the bind mount. >> >> The code better handles the escaped directory returning into it's bind >> mount, and is now roughly a constant factor cost in all cases from what >> the code costs without the fix. >> >> So I think I have found a better tradeoff between fixing this bug and >> not slowing down path name lookups in the common case. > > Maybe I'm missing something, but I see a much simpler fix: > > - When following ".." first just check against the dentry being equal > to the root dentry. > > - If so, then check mount being equal to root mount. > > - If so, then we are fine, found the root. > > - If mount is not root mount, then we either have a bind mount or the > escape scenario. So have a peek at the mount tree to see if we have a > chance of reaching root or not. > > - If yes, then we are fine, continue upward. > > - Otherwise stop here and act like we found root. In concrete terms I think you are suggesting something like this patch to follow_dot_dot. > This doesn't have to hook into d_move() and will only trigger the > "violated" mode on an very specific and rare case. Am I misunderstanding you? I don't think .. on a bind mount is a very specific rare case. Operations such as following ../../../../../../../../../.. would go from a cost of O(10) to a cost of O((10*(10 + P + 1))/2) aka from O(N) to O(N^2+N*P). Where P is the depth of the path below 10 directories up. Given that in cases like containers bind mounts are frequently the root mount point of a filesystem I don't think we want that expense, if we can possibly avoid it. As that is a DOS attack and messes up performance for cases that are not afflicected with an escape. Eric --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/namei.c b/fs/namei.c index ae4e4c18b2ac..56a8562899a1 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1409,6 +1409,11 @@ static void follow_dotdot(struct nameidata *nd) break; } if (nd->path.dentry != nd->path.mnt->mnt_root) { + /* Escaped path? */ + if ((nd->path.mnt->mnt_root != nd->path.mnt->mnt_sb->s_root) && + d_ancestor(nd->path.mnt->mnt_root, nd->path.dentry)) + break; + } /* rare case of legitimate dget_parent()... */ nd->path.dentry = dget_parent(nd->path.dentry); dput(old);