Re: question about /proc/<PID>/mem in 2.4 (fwd)

From: Willy Tarreau
Date: Sun Jul 18 2004 - 16:33:09 EST


Hi !

On Sun, Jul 18, 2004 at 04:59:25PM +0400, Solar Designer wrote:
> On Sun, Jul 18, 2004 at 01:41:34PM +0100, Tigran Aivazian wrote:
[...]
> > # setuidapp < /proc/self/mem
> >
> > and this program reading stdin.
>
> The problem is the program does not know its stdin corresponds to a
> process' address space and it does not know it is making use of a
> privilege to read it. A correctly written SUID root program may
> reasonably assume that the data it obtains from stdin is whatever the
> unprivileged user has provided, -- and, for example, display such data
> back to the user (as a part of an error message or so). If we permit
> reads from /proc/<pid>/mem based on credentials of the read(2)-calling
> process only, this assumption would be violated resulting in security
> holes.

unless I'm mistaken, it will be the shell which will open /proc/self/mem,
so if it doesn't have correct rights, even the setuidapp will not have
access to it because the shell will not be able to open the file.

> Oh, by the way, I've just noticed that the above example is not
> entirely correct. In order to read setuidapp's own address space
> (after the kernel has been patched according to your proposal), it
> should have been:
>
> $ exec setuidapp < /proc/self/mem

Hmm, this is an interesting case. What exactly is passed then ? You agree
that the shell opens its own memory map on fd 0 then execs setuidapp
which will have it on stdin. But will the fd contents be automatically
replaced with the new process' memory map or will it still be the shell's
until this last reference is dropped ?

Cheers,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/