public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Stanislav Kinsburskiy <skinsbursky@virtuozzo.com>,
	peterz@infradead.org, mingo@redhat.com, mhocko@suse.com,
	keescook@chromium.org, linux-kernel@vger.kernel.org,
	mguzik@redhat.com, bsegall@google.com, john.stultz@linaro.org,
	oleg@redhat.com, matthltc@us.ibm.com, akpm@linux-foundation.org,
	luto@amacapital.net, vbabka@suse.cz, xemul@virtuozzo.com
Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link
Date: Tue, 26 Jul 2016 11:34:45 +0300	[thread overview]
Message-ID: <20160726083445.GB26208@uranus> (raw)
In-Reply-To: <87a8h58pac.fsf@x220.int.ebiederm.org>

On Mon, Jul 25, 2016 at 02:56:43PM -0500, Eric W. Biederman wrote:
...
> >>
> >> Also there is a big fat bug in prctl_set_mm_exe_file.  It doesn't
> >> validate that the new file is a actually mmaped executable.  We would
> >> definitely need that to be fixed before even considering removing the
> >> limit.
> >
> > Could you please elaborate? We check for inode being executable,
> > what else needed?
> 
> That the inode is mmaped into the process with executable mappings.
> 
> Effectively what we check the old mapping for and refuse to remove the old
> mm_exe_file if it exists.
> 
> I think a reasonable argument can be made that if the file is
> executable, and it is mmaped with executable pages that exe_file is not
> a complete lie.

I might be missing something obvious, so sorry for the question --
when criu setups old exe link the inode we obtain from file open
is not mapped into memory, the old exe not read by anyone because
it's not even executed anyhow. So I don't really understand which
mapping we should check here. Mind to point me?

> Which is the important part.  At the end of the day how much can
> userspace trust /proc/pid/exe?  If we are too lax it is just a random
> file descriptor we can not trust at all.  At which point there is
> exactly no point in preserving it in checkpoint/restart, because nothing
> will trust or look at it.

You know, I think we should not trust exe link much, and in real we
never could: this link is rather a hint pointing which executable a
process has been using on execve call, once the process start working
one can't be sure if the code currently running is exactly from the
file pointed by exe link. It just a hint suitable for debuggin and
obtain clean view of which processes are running on noncompromised
system. Monitoring exe link change won't help much if there are
malicious software running on the system.

> If the only user is checkpoint/restart perhaps it should be only ptrace
> that can set this and not the process itself with a prctl.  I don't
> know.  All I know is that we should work on making it a very trustable
> value even though in some specific instances we can set it.

Since as I said I suppose nobody except us using this feature, we can
setup some sysctl trigger for it (I personally think this is an
overkill, but OTOH if people rely on the exe link and not going
to use criu at all, this trigger will help).

	Cyrill

  reply	other threads:[~2016-07-26  8:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12 15:30 [PATCH] prctl: remove one-shot limitation for changing exe link Stanislav Kinsburskiy
2016-07-12 16:42 ` Oleg Nesterov
2016-07-12 16:52   ` Stanislav Kinsburskiy
2016-07-12 17:01     ` Oleg Nesterov
2016-07-12 16:48 ` Cyrill Gorcunov
2016-07-12 16:52   ` Eric W. Biederman
2016-07-12 17:29     ` Cyrill Gorcunov
2016-07-12 21:42       ` Cyrill Gorcunov
2016-07-13 10:47     ` Stanislav Kinsburskiy
2016-07-18 20:11     ` One Thousand Gnomes
2016-07-20 11:30       ` Stanislav Kinsburskiy
     [not found] ` <8a863273-c571-63d6-c0c3-637dff5645a3@virtuozzo.com>
2016-07-25 18:21   ` Eric W. Biederman
2016-07-25 19:22     ` Cyrill Gorcunov
2016-07-25 19:56       ` Eric W. Biederman
2016-07-26  8:34         ` Cyrill Gorcunov [this message]
2016-07-30 17:31           ` Eric W. Biederman
2016-07-30 20:28             ` Mateusz Guzik
2016-07-31 18:45               ` Eric W. Biederman
2016-08-22 15:40                 ` Richard Guy Briggs
2016-07-31 22:43             ` Cyrill Gorcunov
2016-07-31 22:49               ` Andy Lutomirski
2016-08-01  9:04             ` Cyrill Gorcunov
2016-08-10 10:48             ` Stanislav Kinsburskiy
2016-07-26 10:21     ` Stanislav Kinsburskiy
  -- strict thread matches above, loose matches on Subject: below --
2016-07-12 15:42 Stanislav Kinsburskiy
     [not found] <1d254efe-5410-40c4-af4b-9e898682d0b3@email.android.com>
2016-07-13 10:15 ` Oleg Nesterov

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=20160726083445.GB26208@uranus \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bsegall@google.com \
    --cc=ebiederm@xmission.com \
    --cc=john.stultz@linaro.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=matthltc@us.ibm.com \
    --cc=mguzik@redhat.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=skinsbursky@virtuozzo.com \
    --cc=vbabka@suse.cz \
    --cc=xemul@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox