From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Pavel Emelyanov <xemul@parallels.com>,
Kees Cook <keescook@chromium.org>, Tejun Heo <tj@kernel.org>
Subject: Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file
Date: Mon, 5 Mar 2012 20:01:27 +0400 [thread overview]
Message-ID: <20120305160127.GM7366@moon> (raw)
In-Reply-To: <20120305154029.GB12427@redhat.com>
On Mon, Mar 05, 2012 at 04:40:29PM +0100, Oleg Nesterov wrote:
> >
> > Hi Oleg!
> >
> > Replying to both your email -- I wanted to be as close to open_exec
> > as possible.
>
> I see. But open_exec() is different, it returns the file we are going
> to read/mmap. PR_SET_MM_EXE_FILE is different, I think O_RDONLY buys
> nothing and looks confusing.
>
> Anyway, as I said I won't argue.
>
OK
> > This prctl does cheat the kernel
>
> Yep. Except, well, it cheats the user-space.
And kernel as well, since this link is not anymore
the same as it was, and memory read from this file
(at execution time) will keep data irrelevant to what
the new symlink points to (but it's exactly by design).
>
> > but with this tests
> > the cheating should be minimized (it's almost the same as open_exec
> > does).
>
> I don't reallt understand "minimized" ;) With this tests
> proc/pid/exe can't look "obviously wrong", I agree. But that is all.
call it "minimized wrong" ;)
>
> > > Seriously, I think we should cleanup this before c/r adds more
> > > ugliness. I'll try to make the patch today.
> >
> > Cleanup what? If you mean this patch -- just point me what
> > should I do.
>
> I just sent the patch, "turn mm->exe_file into mm->exe_path"
>
Cool, just got it, thanks!
> > > And with all these checks I am no longer sure that fd is better
> > > than filename ;)
> >
> > This security tests was a reason why I've used open_exec in
> > first version of the patch
>
> Yes, but me and Pavel forced you to use "int fd" ;)
>
With plain fd it doesn't require kernel to allocate temp
memory and copy path from user space, this is a positive
effect.
> > (and I still would prefer to
> > have open_exec here instead of fd).
>
> With the patch I sent "struct file *" is not needed at all.
> I think prctl() can use user_path().
OK!
>
> > As to allow-write-access -- it should be cleaned once process
> > finished, no?
>
> Exactly! And who will increment ->i_writecount? Nobody, that is
> the problem.
I see, thanks!
Cyrill
next prev parent reply other threads:[~2012-03-05 16:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 15:16 [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file Cyrill Gorcunov
2012-02-29 15:23 ` Pavel Emelyanov
2012-02-29 15:31 ` Cyrill Gorcunov
2012-02-29 19:24 ` Oleg Nesterov
2012-02-29 20:01 ` Cyrill Gorcunov
2012-03-01 18:06 ` Oleg Nesterov
2012-03-01 19:17 ` Cyrill Gorcunov
2012-03-01 19:41 ` Oleg Nesterov
2012-03-01 20:00 ` Cyrill Gorcunov
2012-03-02 15:03 ` Oleg Nesterov
2012-03-02 14:26 ` Cyrill Gorcunov
2012-03-02 15:26 ` Oleg Nesterov
2012-03-02 16:12 ` Cyrill Gorcunov
2012-03-03 22:33 ` Cyrill Gorcunov
2012-03-05 14:21 ` Oleg Nesterov
2012-03-05 14:26 ` Oleg Nesterov
2012-03-05 14:46 ` Cyrill Gorcunov
2012-03-05 15:40 ` Oleg Nesterov
2012-03-05 16:01 ` Cyrill Gorcunov [this message]
2012-03-05 16:31 ` Oleg Nesterov
2012-03-05 16:45 ` 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=20120305160127.GM7366@moon \
--to=gorcunov@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox