[lkml]   [2012]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /proc/[pid]/mem write implications

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
> 2004 thread
> 2002 thread
> 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.



 \ /
  Last update: 2012-01-30 09:13    [W:0.037 / U:6.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site