Messages in this thread | | | Date | Fri, 23 Mar 2012 10:06:14 -0700 | From | Matt Helsley <> | Subject | Re: [patch 1/2] c/r: prctl: Add ability to set new mm_struct::exe_file |
| |
On Thu, Mar 22, 2012 at 04:38:43PM -0700, Eric W. Biederman wrote: > Cyrill Gorcunov <gorcunov@openvz.org> writes: > > > On Mon, Mar 19, 2012 at 03:46:49PM -0700, Andrew Morton wrote: > >> > >> > >> > >> What is this mysterious "security reason"? > >> > >> > >> > > > >> > > Oh, sorry I should have included Matt's comment here > >> > >> Please send a patch with the updated changelog and improved comment? > >> > > > > Andrew, take a look please, will the changelog and comments look > > better? > > Can you change this to take an actual address and get the exe_file > from an mmapped area and make certain that the mmaped_area is already > mapped MAP_EXEC.
Do you mean PROT_EXEC/VM_EXEC?
> > That will prevent out-right lies. > > At least then we will know that exe_file will at least be a file that is > mapped executable in the process's address space. It's not a lot better > but it makes /proc/<pid>/exe at almost as trustable as it is now.
I don't dislike the idea. However just because it's mapped with one of those flags does not mean that a single instruction of it will ever be executed. So it's not much better than using the fd :/.
Perhaps there is some way to use the userspace stack and/or regs to get a reasonable instruction pointer, lookup its VMA, and use that? I'm not sure that would work for c/r though...
Cheers, -Matt
| |