[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200716085141.nr4wyeh62ahjwupd@wittgenstein>
Date: Thu, 16 Jul 2020 10:51:41 +0200
From: Christian Brauner <christian.brauner@...ntu.com>
To: Adrian Reber <areber@...hat.com>
Cc: Eric Biederman <ebiederm@...ssion.com>,
Pavel Emelyanov <ovzxemul@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
Andrei Vagin <avagin@...il.com>,
Nicolas Viennot <Nicolas.Viennot@...sigma.com>,
Michał Cłapiński <mclapinski@...gle.com>,
Kamil Yurtsever <kyurtsever@...gle.com>,
Dirk Petersen <dipeit@...il.com>,
Christine Flood <chf@...hat.com>,
Casey Schaufler <casey@...aufler-ca.com>,
Mike Rapoport <rppt@...ux.ibm.com>,
Radostin Stoyanov <rstoyanov1@...il.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Serge Hallyn <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>,
Sargun Dhillon <sargun@...gun.me>,
Arnd Bergmann <arnd@...db.de>,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, selinux@...r.kernel.org,
Eric Paris <eparis@...isplace.org>,
Jann Horn <jannh@...gle.com>, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v5 4/6] proc: allow access in init userns for map_files
with CAP_CHECKPOINT_RESTORE
On Wed, Jul 15, 2020 at 04:49:52PM +0200, Adrian Reber wrote:
> Opening files in /proc/pid/map_files when the current user is
> CAP_CHECKPOINT_RESTORE capable in the root namespace is useful for
> checkpointing and restoring to recover files that are unreachable via
> the file system such as deleted files, or memfd files.
>
> Signed-off-by: Adrian Reber <areber@...hat.com>
> Signed-off-by: Nicolas Viennot <Nicolas.Viennot@...sigma.com>
> ---
> fs/proc/base.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 65893686d1f1..cada783f229e 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2194,16 +2194,16 @@ struct map_files_info {
> };
>
> /*
> - * Only allow CAP_SYS_ADMIN to follow the links, due to concerns about how the
> - * symlinks may be used to bypass permissions on ancestor directories in the
> - * path to the file in question.
> + * Only allow CAP_SYS_ADMIN and CAP_CHECKPOINT_RESTORE to follow the links, due
> + * to concerns about how the symlinks may be used to bypass permissions on
> + * ancestor directories in the path to the file in question.
> */
> static const char *
> proc_map_files_get_link(struct dentry *dentry,
> struct inode *inode,
> struct delayed_call *done)
> {
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_CHECKPOINT_RESTORE))
So right now, when I'd do
git grep checkpoint_restore_ns_capable
I'd not hit that codepath which isn't great. So I'd suggest to use:
if (!checkpoint_restore_ns_capable(&init_user_ns))
at the end of the day, capable(<cap>) just calls
ns_capable(&init_user_ns, <cap>) anyway.
Thanks!
Christian
Powered by blists - more mailing lists