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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 C72DAC433E0 for ; Mon, 15 Feb 2021 17:58:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8BC3764DEC for ; Mon, 15 Feb 2021 17:58:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230280AbhBOR5q (ORCPT ); Mon, 15 Feb 2021 12:57:46 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:36746 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230131AbhBOR5l (ORCPT ); Mon, 15 Feb 2021 12:57:41 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lBi7G-00Ewhl-6H; Mon, 15 Feb 2021 10:56:58 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1lBi7F-0007sy-8Z; Mon, 15 Feb 2021 10:56:57 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Jens Axboe Cc: linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk References: <20201214191323.173773-1-axboe@kernel.dk> <94731b5a-a83e-91b5-bc6c-6fd4aaacb704@kernel.dk> Date: Mon, 15 Feb 2021 11:56:16 -0600 In-Reply-To: <94731b5a-a83e-91b5-bc6c-6fd4aaacb704@kernel.dk> (Jens Axboe's message of "Sun, 14 Feb 2021 09:38:01 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lBi7F-0007sy-8Z;;;mid=;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1967J4c9TL3f1UdqqpMRd1Hs7BR9oOrmT0= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK (Insufficiently faking current?) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Jens Axboe writes: > On 2/13/21 3:08 PM, Eric W. Biederman wrote: >> >> I have to ask. Are you doing work to verify that performing >> path traversals and opening of files yields the same results >> when passed to io_uring as it does when performed by the caller? >> >> Looking at v5.11-rc7 it appears I can arbitrarily access the >> io-wq thread in proc by traversing "/proc/thread-self/". > > Yes that looks like a bug, it needs similar treatment to /proc/self: Agreed. > diff --git a/fs/proc/thread_self.c b/fs/proc/thread_self.c > index a553273fbd41..e8ca19371a36 100644 > --- a/fs/proc/thread_self.c > +++ b/fs/proc/thread_self.c > @@ -17,6 +17,13 @@ static const char *proc_thread_self_get_link(struct dentry *dentry, > pid_t pid = task_pid_nr_ns(current, ns); > char *name; > > + /* > + * Not currently supported. Once we can inherit all of struct pid, > + * we can allow this. > + */ > + if (current->flags & PF_KTHREAD) > + return ERR_PTR(-EOPNOTSUPP); I suspect simply testing for PF_IO_WORKER is a better test. As it is the delegation to the io_worker not the fact that it is a kernel thread that causes a problem. I have a memory of that point being made when the smack_privileged test and the tomoyo_kernel_service test and how to fix them was being discussed. > if (!pid) > return ERR_PTR(-ENOENT); > name = kmalloc(10 + 6 + 10 + 1, dentry ? GFP_KERNEL : GFP_ATOMIC); > > as was done in this commit: > > commit 8d4c3e76e3be11a64df95ddee52e99092d42fc19 > Author: Jens Axboe > Date: Fri Nov 13 16:47:52 2020 -0700 > > proc: don't allow async path resolution of /proc/self components I suspect that would be better as PF_IO_WORKER as well. >> Similarly it looks like opening of "/dev/tty" fails to >> return the tty of the caller but instead fails because >> io-wq threads don't have a tty. >> >> >> There are a non-trivial number of places where current is used in the >> kernel both in path traversal and in opening files, and I may be blind >> but I have not see any work to find all of those places and make certain >> they are safe when called from io_uring. That worries me as that using >> a kernel thread instead of a user thread could potential lead to >> privilege escalation. > > I've got a patch queued up for 5.12 that clears ->fs and ->files for the > thread if not explicitly inherited, and I'm working on similarly > proactively catching these cases that could potentially be > problematic. Any pointers or is this all in a private tree for now? It is difficult to follow because many of the fixes have not CC'd the reporters or even the maintainers of the subsystems who have been affected by this kind of issue. Eric