Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3034655imu; Mon, 19 Nov 2018 09:38:52 -0800 (PST) X-Google-Smtp-Source: AJdET5fM21wMOKhODQz+Ay8fNCg6JwgxlNJI6suwJfsN6pvbdq0fODYEbOK0L3kPV1BgnyFyZn2/ X-Received: by 2002:a65:5387:: with SMTP id x7mr21059380pgq.412.1542649132308; Mon, 19 Nov 2018 09:38:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542649132; cv=none; d=google.com; s=arc-20160816; b=QNkGS6v578nPOvNw96B8XhsQgGxKPlYZKnh9jjya66ExMx/Le50tFUsRUwKGVT4nCn YP1zbrAhAxMgrKmu+Ol8+vgy92PmujjWiVKM/oqQUGk2jFUwxk03maKvVXxBEyZ/LNwF ZhS/CeA1rDJf2dycctt3mzplORGLJwszo9lHcd9QCucsTeMUhwQgP8+9UVCgDwmPuiPz kjBKatN+Q0ys3jyUy9+Mxg8Z7KueT9io7Hg8/k3PGTdrLg6kcxZyUmwZgxiBtvXRq+aE yvJwnHMHMIGV3clJbld3+h1msoRauLCaSNQL3t79m/NcxaBO67lWcGYzyrrqCFKRzx2s 7OPg== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=dAs5fTacM+xFnqoep9cnLbSlWmIhxzLx0uDj1glJy1c=; b=TAlbQRY41xoCI+RlDA6E4gTlDSejBKHlUCE/9sw4eb2k1iRYicL0nVt/yJHM3vdiTE Oe5fF198IY6G/4FpNdcgAiPlSQt4aFDrCDMURnEkLFLlKgcw4dsVVYNwM4JjGNIYKNhz uVxoC9P760o8+pqebkWJ3zOpsmZ5fT6XfNPcDRT1EBCfCug+Usi53T+dEftHMC8Wdx/E 9uOJa1P7AYVvb5XvZMp+a7c3cciliG8DExH/CYMrh6GXJCpmOEzMcQOwmvLiLHUwTPjr pD9uHDqKAJg2wobxkoo4GUmcfPTn01bc2u4YrjLTAMauNkFpnSS2hHnAcK6gGMXolwQG Hfww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=zfAhsEwo; 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 g3-v6si27940842plt.208.2018.11.19.09.38.36; Mon, 19 Nov 2018 09:38:52 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=zfAhsEwo; 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 S2390119AbeKTDPA (ORCPT + 99 others); Mon, 19 Nov 2018 22:15:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:52408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388976AbeKTDO4 (ORCPT ); Mon, 19 Nov 2018 22:14:56 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4ABA7213A2; Mon, 19 Nov 2018 16:50:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542646243; bh=03NO1ZJ1I1y9zsepBwQQPeTSO8kFYKvn1BwLJgXgDOk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zfAhsEwoJEpUCiZKZj2C0XdVszIZZT2wX1ihexiH3AKCevE3tRzomCUnFG2JEIffe IIC4pKrnmoK+0FkJOG6gmSi7iZT/K42gnjGsszuHLA02Jn3NvkQl+G5Q6L2pUyZWxB Xf2X6HErlzzC58l7wtmdnO8lqVp3587W+LHW8q3o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Timothy Baldwin , "Eric W. Biederman" Subject: [PATCH 4.14 092/124] mount: Prevent MNT_DETACH from disconnecting locked mounts Date: Mon, 19 Nov 2018 17:29:06 +0100 Message-Id: <20181119162630.275723231@linuxfoundation.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181119162612.951907286@linuxfoundation.org> References: <20181119162612.951907286@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric W. Biederman commit 9c8e0a1b683525464a2abe9fb4b54404a50ed2b4 upstream. Timothy Baldwin wrote: > As per mount_namespaces(7) unprivileged users should not be able to look under mount points: > > Mounts that come as a single unit from more privileged mount are locked > together and may not be separated in a less privileged mount namespace. > > However they can: > > 1. Create a mount namespace. > 2. In the mount namespace open a file descriptor to the parent of a mount point. > 3. Destroy the mount namespace. > 4. Use the file descriptor to look under the mount point. > > I have reproduced this with Linux 4.16.18 and Linux 4.18-rc8. > > The setup: > > $ sudo sysctl kernel.unprivileged_userns_clone=1 > kernel.unprivileged_userns_clone = 1 > $ mkdir -p A/B/Secret > $ sudo mount -t tmpfs hide A/B > > > "Secret" is indeed hidden as expected: > > $ ls -lR A > A: > total 0 > drwxrwxrwt 2 root root 40 Feb 12 21:08 B > > A/B: > total 0 > > > The attack revealing "Secret": > > $ unshare -Umr sh -c "exec unshare -m ls -lR /proc/self/fd/4/ 4 /proc/self/fd/4/: > total 0 > drwxr-xr-x 3 root root 60 Feb 12 21:08 B > > /proc/self/fd/4/B: > total 0 > drwxr-xr-x 2 root root 40 Feb 12 21:08 Secret > > /proc/self/fd/4/B/Secret: > total 0 I tracked this down to put_mnt_ns running passing UMOUNT_SYNC and disconnecting all of the mounts in a mount namespace. Fix this by factoring drop_mounts out of drop_collected_mounts and passing 0 instead of UMOUNT_SYNC. There are two possible behavior differences that result from this. - No longer setting UMOUNT_SYNC will no longer set MNT_SYNC_UMOUNT on the vfsmounts being unmounted. This effects the lazy rcu walk by kicking the walk out of rcu mode and forcing it to be a non-lazy walk. - No longer disconnecting locked mounts will keep some mounts around longer as they stay because the are locked to other mounts. There are only two users of drop_collected mounts: audit_tree.c and put_mnt_ns. In audit_tree.c the mounts are private and there are no rcu lazy walks only calls to iterate_mounts. So the changes should have no effect except for a small timing effect as the connected mounts are disconnected. In put_mnt_ns there may be references from process outside the mount namespace to the mounts. So the mounts remaining connected will be the bug fix that is needed. That rcu walks are allowed to continue appears not to be a problem especially as the rcu walk change was about an implementation detail not about semantics. Cc: stable@vger.kernel.org Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users") Reported-by: Timothy Baldwin Tested-by: Timothy Baldwin Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1874,7 +1874,7 @@ void drop_collected_mounts(struct vfsmou { namespace_lock(); lock_mount_hash(); - umount_tree(real_mount(mnt), UMOUNT_SYNC); + umount_tree(real_mount(mnt), 0); unlock_mount_hash(); namespace_unlock(); }