All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Tejun Heo <tj@kernel.org>, Andrew Vagin <avagin@openvz.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Pavel Emelyanov <xemul@parallels.com>,
	Vasiliy Kulikov <segoon@openwall.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [RFC 2/2] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation
Date: Wed, 9 Jul 2014 02:13:36 +0400	[thread overview]
Message-ID: <20140708221336.GL17860@moon.sw.swsoft.com> (raw)
In-Reply-To: <20140708143830.ea078ef01e1d7d31276edbcd@linux-foundation.org>

On Tue, Jul 08, 2014 at 02:38:30PM -0700, Andrew Morton wrote:
> On Tue, 8 Jul 2014 23:08:49 +0400 Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> 
> > Ping. Guys, any commens please?
> 
> Well, allowing a process to modify pretty deep internals like this is
> always scary from a security point of view, and now we're removing
> CAP_SYS_RESOURCE protections.  Yikes.  Convince me we aren't handing
> out root here.
> 
> The changelog doesn't make it clear (to me) why this is actually being
> done.  criu runs unprivileged?  What's the requirement here?

It comes from user-ns, we are almost ready to support c/r for user
namespaces and faced a problem -- when we create new user-namespace
we loose CAP_SYS_RESOURCE bit and criu fails to proceed. Andrew
Vagin was implementing user-ns in criu and as far as I remember
there were a talk with Eric which (again if my memory doesn't
betray me) end up in -- guys, simply do proper check for values
you read from user space instead of relying on CAP_SYS_RESOURCE.
Erik, am I right?

Probably I should walk over _every_ member we're modifying
explaning where exactly is used in kernel.

Still the good news about all this members we modify -- they are used
for statistics mostly except brk/stack related members but they
are checked very carefully to not exceed the limits (if the
limits are set).

> struct prctl_mm_map could do with a nice comment explaining its role in
> the world.

ok, i'll update

> I'm not seeing a coherent description of the proposed userspace
> interface.  We'll eventually want to update the prctl manpage for this,
> so how about laying out all the needed details now, at patch review
> time so we can see what is proposed.

Sure, I'll write more descriptive comment since original "It takes
a pointer of prctl_mm_map structure which carries all members to be
updated" is too short.

> 
> Why isn't the newly-added code under #ifdef CONFIG_CHECKPOINT_RESTORE?

Initially all prctl set-mm opcodes were CONFIG_CHECKPOINT_RESTORE
guarded but then assumed that such modification might be
needed not only for criu but other tools as well and this #ifdef
were dropped off. Now new PR_SET_MM_MAP is a part of old
interface so I'm not sure if it should be CONFIGed. That
said it is not a problem to wrap it but looks unreasonable
in this particular case.

  reply	other threads:[~2014-07-08 22:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-03 14:33 [RFC 0/2] prctl: set-mm -- Rework interface Cyrill Gorcunov
2014-07-03 14:33 ` [RFC 1/2] prctl: PR_SET_MM -- Factor out mmap_sem when update mm::exe_file Cyrill Gorcunov
2014-07-03 14:33 ` [RFC 2/2] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation Cyrill Gorcunov
2014-07-03 20:34   ` Cyrill Gorcunov
2014-07-04  7:52   ` Andrew Vagin
2014-07-04  8:11     ` Cyrill Gorcunov
2014-07-08 19:08   ` Cyrill Gorcunov
2014-07-08 21:38     ` Andrew Morton
2014-07-08 22:13       ` Cyrill Gorcunov [this message]
2014-07-09 14:13         ` Cyrill Gorcunov
2014-07-09 14:53           ` Kees Cook
2014-07-09 15:06             ` Cyrill Gorcunov
2014-07-11 17:36               ` Cyrill Gorcunov
2014-07-22 20:07                 ` Kees Cook
2014-07-22 20:36                   ` Cyrill Gorcunov
2014-07-24 13:48                   ` Andrew Vagin
2014-07-24 16:42                     ` Cyrill Gorcunov
2014-07-24 18:44                     ` Kees Cook
2014-07-24 18:50                       ` Cyrill Gorcunov

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=20140708221336.GL17860@moon.sw.swsoft.com \
    --to=gorcunov@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=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.