Re: /proc/$PID/mem rationale

From: Valdis . Kletnieks
Date: Wed May 04 2005 - 12:33:52 EST

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: pgp00000.pgp
Description: PGP signature