linux-kernel - Re: [PATCH] proc: prevent mount proc on same mountpoint in one pid namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210822130630.GA39585@www>
Date:   Sun, 22 Aug 2021 06:06:30 -0700
From:   CGEL <cgel.zte@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     christian.brauner@...ntu.com, jamorris@...ux.microsoft.com,
        gladkov.alexey@...il.com, yang.yang29@....com.cn, tj@...nel.org,
        paul.gortmaker@...driver.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, Zeal Robot <zealci@....com.cn>
Subject: Re: [PATCH] proc: prevent mount proc on same mountpoint in one pid
 namespace

On Sat, Aug 21, 2021 at 02:10:16PM +0000, Al Viro wrote:
> On Sat, Aug 21, 2021 at 01:31:05AM -0700, cgel.zte@...il.com wrote:
> > From: Yang Yang <yang.yang29@....com.cn>
> > 
> > Patch "proc: allow to mount many instances of proc in one pid namespace"
> > aims to mount many instances of proc on different mountpoint, see
> > tools/testing/selftests/proc/proc-multiple-procfs.c.
> > 
> > But there is a side-effects, user can mount many instances of proc on
> > the same mountpoint in one pid namespace, which is not allowed before.
> > This duplicate mount makes no sense but wastes memory and CPU, and user
> > may be confused why kernel allows it.
> > 
> > The logic of this patch is: when try to mount proc on /mnt, check if
> > there is a proc instance mount on /mnt in the same pid namespace. If
> > answer is yes, return -EBUSY.
> > 
> > Since this check can't be done in proc_get_tree(), which call
> > get_tree_nodev() and will create new super_block unconditionally.
> > And other nodev fs may faces the same case, so add a new hook in
> > fs_context_operations.
> 
> NAK.  As attack prevention it's worthless (you can just bind-mount
> a tmpfs directory between them).  Besides, filesystem does *not*
> get to decide where it would be mounted.  Especially since it couldn't
> rely upon that, anyway, what with mount --bind possible *after* it had
> been initially mounted.

Thanks for your relpy! No doubt anymore.