Messages in this thread | | | Date | Mon, 30 Jan 2012 09:10:03 +0100 | Subject | Re: /proc/[pid]/mem write implications | From | "Indan Zupancic" <> |
| |
Hello,
On Sun, January 29, 2012 15:19, Alan Cox wrote: >> > But I think that allowing arbitrary processes to write to **their own** >> > memory via a file descriptor might in itself be problematic. Please, >> > help me understand how this is safe. >> >> You will have a sysctl to control if it is writable. > > The problem is not that the check is done in write, the problem is more > fundamental - the open should bind to the memory of the executable image > currently running, instead it effectively late binds each write to the > image now being run. That is the root cause. > > What's sad about this is that people went and re-introduced the bug and > clearly didn't think to spend 2 minutes asking Google why the checks were > there originally.
How did the patch enabling it get past review?
> > 2006 thread > > http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1359.html > > 2004 thread > > http://lkml.indiana.edu/hypermail/linux/kernel/0407.0/1169.html > > 2002 thread > > http://www.eros-os.org/pipermail/cap-talk/2002-May/000922.html > > > If you really want to fix this then you need to bind /proc/self/mem to > the executable image in question, and you need to effectively revoke() > that on exec so it can't be used to pin old images into memory. > > Fix that and the rest falls out in the wash.
There is process_vm_writev() now, so there is no need for a writeable /proc/*/mem. User space can't count on it being writeable anyway.
Actually, as there is process_vm_readv() too now, I think /proc/*/mem should be removed altogether.
Greetings,
Indan
| |