From: Cyrill Gorcunov <gorcunov@gmail.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrew Vagin <avagin@openvz.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
Vasiliy Kulikov <segoon@openwall.com>,
Kees Cook <keescook@chromium.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Pavel Emelyanov <xemul@parallels.com>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [patch 3/3] [PATCH] prctl: Add PR_SET_MM codes to set up mm_struct entires v3
Date: Tue, 13 Dec 2011 01:58:40 +0400 [thread overview]
Message-ID: <20111212215840.GS2199@moon> (raw)
In-Reply-To: <4EE676F2.1020204@gmail.com>
On Mon, Dec 12, 2011 at 04:49:38PM -0500, KOSAKI Motohiro wrote:
> Hi
>
> > When we restore a task we need to set up text, data and data
> > heap sizes from userspace to the values a task had at
> > checkpoint time. This patch adds auxilary prctl codes for that.
> >
> > While most of them have a statistical nature (their values
> > are involved into calculation of /proc/<pid>/statm output)
> > the start_brk and brk values are used to compute an allowed
> > size of program data segment expansion. Which means an arbitrary
> > changes of this values might be dangerous operation. So to restrict
> > access the following requirements applied to prctl calls:
> >
> > - The process has to have CAP_SYS_ADMIN capability granted.
>
> This is very dangerous feature and useless from regular admins.
Except brk() call I don't see where it might be extremelly
dangerous at moment but indeed it might become very dangerous
once code grows. Still if evil minded person got CAP_SYS_ADMIN
these prctls are least thing one should carry about.
> Moreover, CAP_SYS_ADMIN has a pretty overweight meanings and
> we can't disable it on practical. So, I have a question. Why
> don't you make new capability for checkpoint?
>
It's not a problem to introduce CAP_CHECKPOINT_RESTORE, but
would it be accepted? I mean, are we fine with new capability
introduction? If yes -- I'll add new one and rebase the patch.
Cyrill
next prev parent reply other threads:[~2011-12-12 21:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 20:06 [patch 0/3] Patches in a sake of checkpoint/restore, procfs and prctls Cyrill Gorcunov
2011-12-12 20:06 ` [patch 1/3] Kconfig: Introduce CHECKPOINT_RESTORE symbol Cyrill Gorcunov
2011-12-12 20:40 ` Kees Cook
2011-12-12 20:06 ` [patch 2/3] [PATCH] fs, proc: Add start_data, end_data, start_brk members to /proc/$pid/stat v4 Cyrill Gorcunov
2011-12-12 20:06 ` [patch 3/3] [PATCH] prctl: Add PR_SET_MM codes to set up mm_struct entires v3 Cyrill Gorcunov
2011-12-12 20:38 ` Kees Cook
2011-12-12 20:51 ` Cyrill Gorcunov
2011-12-12 21:53 ` Andrew Morton
2011-12-12 22:01 ` Cyrill Gorcunov
2011-12-12 22:05 ` Cyrill Gorcunov
2011-12-12 21:49 ` KOSAKI Motohiro
2011-12-12 21:58 ` Cyrill Gorcunov [this message]
2011-12-12 22:24 ` KOSAKI Motohiro
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=20111212215840.GS2199@moon \
--to=gorcunov@gmail.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=ebiederm@xmission.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=keescook@chromium.org \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.com \
--cc=tj@kernel.org \
--cc=xemul@parallels.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.