lkml.org 
[lkml]   [2005]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: /proc/$PID/mem rationale
From
Date
On Wed, 04 May 2005 17:40:31 +0200, Serge van den Boom said:

> Could someone explain the reasoning behind these two design decisions
> regarding /proc/$PID/mem?
> - You can only read() from this file from a process which is attached to
> the file's process through ptrace(). Why this requirement?
> The following command line could be rather useful, but the ptrace()
> requirement prevents this from working:
> dd if=/proc/$SOME_PID/mem bs=1 seek=$ADDRESS

It's prohibited *because* it could be rather useful - to a hacker. It's an
issue of information leakage - there are some corner cases where the permissions
on /proc/PID/mem would appear to allow a read, but you don't in fact want to
allow it (for the full list, look at the ptrace() code and the tests it makes
for things like euid != uid and so on). There's a bunch of race conditions
in there too.

> - You can only read() from the mem file from the process that open()ed it.
> Even if the ptrace() requirement were dropped, you wouldn't be able
> to do something like the following command because of this:
> dd bs=1 seek=$ADDRESS < /proc/$SOME_PID/mem

Same reasons. ptrace() is able to make some checks and set some bits that
read() isn't allowed anywhere near (in particular, ptrace() can *stop* a process
so it can't race - read() can't do that.)


[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-05-04 19:36    [W:0.060 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site