From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Adrian Reber <areber@redhat.com>
Cc: "Christian Brauner" <christian.brauner@ubuntu.com>,
"Eric Biederman" <ebiederm@xmission.com>,
"Pavel Emelyanov" <ovzxemul@gmail.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Dmitry Safonov" <0x7f454c46@gmail.com>,
"Andrei Vagin" <avagin@gmail.com>,
"Nicolas Viennot" <Nicolas.Viennot@twosigma.com>,
"Michał Cłapiński" <mclapinski@google.com>,
"Kamil Yurtsever" <kyurtsever@google.com>,
"Dirk Petersen" <dipeit@gmail.com>,
"Christine Flood" <chf@redhat.com>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"Mike Rapoport" <rppt@linux.ibm.com>,
"Radostin Stoyanov" <rstoyanov1@gmail.com>,
"Serge Hallyn" <serge@hallyn.com>,
"Stephen Smalley" <stephen.smalley.work@gmail.com>,
"Sargun Dhillon" <sargun@sargun.me>,
"Arnd Bergmann" <arnd@arndb.de>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, selinux@vger.kernel.org,
"Eric Paris" <eparis@parisplace.org>,
"Jann Horn" <jannh@google.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] capabilities: Introduce CAP_CHECKPOINT_RESTORE
Date: Tue, 9 Jun 2020 21:45:17 +0300 [thread overview]
Message-ID: <20200609184517.GL134822@grain> (raw)
In-Reply-To: <20200603162328.854164-2-areber@redhat.com>
On Wed, Jun 03, 2020 at 06:23:26PM +0200, Adrian Reber wrote:
> This patch introduces CAP_CHECKPOINT_RESTORE, a new capability facilitating
> checkpoint/restore for non-root users.
>
> Over the last years, The CRIU (Checkpoint/Restore In Userspace) team has been
> asked numerous times if it is possible to checkpoint/restore a process as
> non-root. The answer usually was: 'almost'.
>
> The main blocker to restore a process as non-root was to control the PID of the
> restored process. This feature available via the clone3 system call, or via
> /proc/sys/kernel/ns_last_pid is unfortunately guarded by CAP_SYS_ADMIN.
...
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index d86c0afc8a85..ce02f3a4b2d7 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2189,16 +2189,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)))
> return ERR_PTR(-EPERM);
First of all -- sorry for late reply. You know, looking into this code more
I think this CAP_SYS_ADMIN is simply wrong: for example I can't even fetch
links for /proc/self/map_files. Still /proc/$pid/maps (which as well points
to the files opened) test for ptrace-read permission. I think we need
ptrace-may-attach test here instead of these capabilities (if I can attach
to a process I can read any data needed, including the content of the
mapped files, if only I'm not missing something obvious).
next prev parent reply other threads:[~2020-06-09 18:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 16:23 [PATCH v2 0/3] capabilities: Introduce CAP_CHECKPOINT_RESTORE Adrian Reber
2020-06-03 16:23 ` [PATCH v2 1/3] " Adrian Reber
2020-06-03 17:01 ` Cyrill Gorcunov
2020-06-09 3:42 ` Andrei Vagin
2020-06-09 7:44 ` Christian Brauner
2020-06-09 16:06 ` Andrei Vagin
2020-06-09 16:14 ` Christian Brauner
2020-06-10 7:59 ` Andrei Vagin
2020-06-10 15:41 ` Casey Schaufler
2020-06-10 15:48 ` Christian Brauner
2020-06-09 18:45 ` Cyrill Gorcunov [this message]
2020-06-09 20:09 ` Nicolas Viennot
2020-06-09 21:05 ` Eric W. Biederman
2020-06-09 21:28 ` Cyrill Gorcunov
2020-06-03 16:23 ` [PATCH v2 2/3] selftests: add clone3() CAP_CHECKPOINT_RESTORE test Adrian Reber
2020-06-03 16:23 ` [PATCH v2 3/3] prctl: Allow ptrace capable processes to change exe_fd Adrian Reber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200609184517.GL134822@grain \
--to=gorcunov@gmail.com \
--cc=0x7f454c46@gmail.com \
--cc=Nicolas.Viennot@twosigma.com \
--cc=areber@redhat.com \
--cc=arnd@arndb.de \
--cc=avagin@gmail.com \
--cc=casey@schaufler-ca.com \
--cc=chf@redhat.com \
--cc=christian.brauner@ubuntu.com \
--cc=dipeit@gmail.com \
--cc=ebiederm@xmission.com \
--cc=eparis@parisplace.org \
--cc=jannh@google.com \
--cc=kyurtsever@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mclapinski@google.com \
--cc=oleg@redhat.com \
--cc=ovzxemul@gmail.com \
--cc=rppt@linux.ibm.com \
--cc=rstoyanov1@gmail.com \
--cc=sargun@sargun.me \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=stephen.smalley.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.