From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com ([74.125.82.66]:50553 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752244AbeFFP0t (ORCPT ); Wed, 6 Jun 2018 11:26:49 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: [PATCH] ksys_mount: check for permissions before resource allocation From: Ilya Matveychikov In-Reply-To: <87muw8805z.fsf@xmission.com> Date: Wed, 6 Jun 2018 19:26:44 +0400 Cc: linux-kernel@vger.kernel.org, Alexander Viro , linux-fsdevel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87o9gpatxs.fsf@xmission.com> <64021AF2-81EE-439C-91D4-9A33AB0D08F7@gmail.com> <87muw8805z.fsf@xmission.com> To: "Eric W. Biederman" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > On Jun 6, 2018, at 6:22 PM, Eric W. Biederman = wrote: >=20 > Ilya Matveychikov writes: >=20 >>> On Jun 5, 2018, at 11:56 PM, Eric W. Biederman = wrote: >>>=20 >>> Ilya Matveychikov writes: >>>=20 >>>> Just CC=E2=80=99ed to some of maintainers. >>>>=20 >>>> $ perl scripts/get_maintainer.pl = fs/0001-ksys_mount-check-for-permissions-before-resource-all.patch >>>> Alexander Viro (maintainer:FILESYSTEMS = (VFS and infrastructure)) >>>> linux-fsdevel@vger.kernel.org (open list:FILESYSTEMS (VFS and = infrastructure)) >>>> linux-kernel@vger.kernel.org (open list) >>>>=20 >>>>> On Jun 5, 2018, at 6:00 AM, Ilya Matveychikov = wrote: >>>>>=20 >>>>> Early check for mount permissions prevents possible allocation of = 3 >>>>> pages from kmalloc() pool by unpriveledged user which can be used = for >>>>> spraying the kernel heap. >>>=20 >>> *Snort* >>>=20 >>> You clearly have not read may_mount. Your modified code still >>> let's unprivileged users in. So even if all of Al's good objections >>> were not applicable this change would still be buggy and wrong. >>>=20 >>> Nacked-by: "Eric W. Biederman" >>=20 >>=20 >> Don=E2=80=99t get me wrong but may_mount() is: >>=20 >> static inline bool may_mount(void) >> { >> return ns_capable(current->nsproxy->mnt_ns->user_ns, = CAP_SYS_ADMIN); >> } >>=20 >> What do you mean by "You clearly have not read may_mount=E2=80=9D? = The only thing that >> can affect may_mount result (as mentioned earlier) is that task=E2=80=99= s NS capability >> might be changed by security_sb_mount() hook. >>=20 >> So, do you think that is=E2=80=99s possible to NOT have CAP_SYS_ADMIN = while entering to >> ksys_mount() but getting it with the security_sb_mount() hook? >=20 > I mean it works for unprivileged users. >=20 > You can try "unshare -Urm" on a reasonably recent kernel and it will > work and you can then mount and unmount things. >=20 > Strictly speaking it only works if you have the appropriate set of > capabilities in your user namespace. But that does not imply you are = a > privileged user in the broader sense. >=20 > Any user can create a user namespace, and become the root user > in a user namespace. The root user in a user namespace can create > a mount namespace. The root user in a user namespace can mount > and unmount filesystems in their namespace. >=20 > Or in net anyone can call mount and get past the may_mount test. >=20 > Without reducing who can cause the kernel allocation moving the test = is > pointless. >=20 Ok, now I see. No reason to make change as it doesn=E2=80=99t really = prevents users of doing mount() using they own namespaces. Thank you for the explanation.