From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752999AbdEEUfN (ORCPT ); Fri, 5 May 2017 16:35:13 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:33261 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751466AbdEEUfL (ORCPT ); Fri, 5 May 2017 16:35:11 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Al Viro Cc: Linus Torvalds , Jann Horn , Linux API , Linux Kernel Mailing List , linux-fsdevel , David Drysdale References: <20170429220414.GT29622@ZenIV.linux.org.uk> <20170505003030.GM29622@ZenIV.linux.org.uk> <20170505043902.GP29622@ZenIV.linux.org.uk> Date: Fri, 05 May 2017 15:28:47 -0500 In-Reply-To: <20170505043902.GP29622@ZenIV.linux.org.uk> (Al Viro's message of "Fri, 5 May 2017 05:39:02 +0100") Message-ID: <8737cj6oao.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1d6jwO-00087v-Ou;;;mid=<8737cj6oao.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.233.227;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19S3Jj7yV89er9XcfbWwkxsqUvkTf4/KKo= X-SA-Exim-Connect-IP: 67.3.233.227 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4998] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Al Viro X-Spam-Relay-Country: X-Spam-Timing: total 5307 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 2.5 (0.0%), b_tie_ro: 1.64 (0.0%), parse: 1.27 (0.0%), extract_message_metadata: 18 (0.3%), get_uri_detail_list: 3.7 (0.1%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.19 (0.0%), tests_pri_-900: 1.09 (0.0%), tests_pri_-400: 23 (0.4%), check_bayes: 22 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 7 (0.1%), b_comp_prob: 2.8 (0.1%), b_tok_touch_all: 2.9 (0.1%), b_finish: 0.61 (0.0%), tests_pri_0: 193 (3.6%), check_dkim_signature: 0.82 (0.0%), check_dkim_adsp: 3.5 (0.1%), tests_pri_500: 5058 (95.3%), poll_dns_idle: 5053 (95.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: new ...at() flag: AT_NO_JUMPS X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Al Viro writes: > On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote: >> On Thu, May 4, 2017 at 7:47 PM, Jann Horn wrote: >> > >> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd >> > pointing to /srv/www/example.org/foo; the path given to the syscall is >> > "bar/../../../../etc/passwd". The path walk enters the "bar" directory. >> > Thread 2 moves /srv/www/example.org/foo/bar to >> > /srv/www/example.org/bar. >> > Thread 1 processes the rest of the path ("../../../../etc/passwd"), never >> > hitting /srv/www/example.org/foo in the process. >> > >> > I'm not really familiar with the VFS internals, but from a coarse look >> > at the patch, it seems like it wouldn't block this? >> >> I think you're right. >> >> I guess it would be safe for the RCU case due to the sequence number >> check, but not the non-RCU case. > > Yes and no... FWIW, to exclude that it would suffice to have > mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first. > Then this kind of race will end up with -ENOENT due to path_connected() > logics in follow_dotdot_rcu()/follow_dotdot(). I'm not sure about the > intended applications, though - is that thing supposed to be used along with > some horror like seccomp, or...? As I recall the general idea is that if you have an application like a tftp server or a web server that gets a path from a possibly dubious source. Instead of implementing an error prone validation logic in userspace you can use AT_BENEATH and be certain the path resolution stays in bounds. As you can do stronger things as root this seems mostly targeted at non-root applications. I seem to recall part of the idea was to sometimes pair this to seccomp to be certain your application can't escape a sandbox. That plays to seccomp limitations that it can inspect flags as they reside in registers but seccomp can't follow pointers. Which all suggests that we would want something similar to is_subdir when AT_BENEATH is specified that we check every time we follow .. that would verify that on the same filesystem we stay below and that we also stay on a mount that is below. mount --move has all of the same challenges for enforcing you stay within bounds as rename does. Eric