Re: /proc/$PID/mem rationale

[Valdis.Kletnieks@vt.edu]

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.)

Attachment: pgpfIsNsxaqTY.pgp
Description: PGP signature