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

[Tigran Aivazian]

just another attempt, in hope that perhaps the extra "dot" in the email 
address was actually meant to be "." to prevent spam.

Kind regards
Tigran

---------- Forwarded message ----------
Date: Wed, 7 Jul 2004 14:53:44 +0100 (BST)
From: Tigran Aivazian <tigran@xxxxxxxxxxxxxxxxxxxx>
To: solar@xxxxxxxxxxxxxxxx
Cc: Alan Cox <alan@xxxxxxxxxx>, Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx>,
     linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: question about /proc/<PID>/mem in 2.4

On Tue, 6 Jul 2004, Alan Cox wrote:

> On Tue, Jul 06, 2004 at 02:08:04PM +0100, Tigran Aivazian wrote:
> > > This code was added to stop the ptrace/kmod vulnerabilities. I do not 
> > > fully understand the issues around tsk->is_dumpable and the fix itself,
> > > but I agree on that the checks here could be relaxed for the super user.
> 
> is_dumpable tells you various things in 2.4, including whether the
> curent memory image is valid, and as a race preventor for ptrace during
> exec of setuid apps. You should probably talk to Solar Designer about
> the whole design of the dump/suid race fixing work rather than me.
> 
> We also had to deal with another nasty case which could be fixed by grabbing
> the mm at open time (which then opens a resource attack bug).
> 
> Consider what happens if your setuid app reads stdin
> 
> 	setuidapp < /proc/self/mem
> 
> (No idea how 2.6 deals with these but if its got better backportable ways
>  that *actually work* it might make sense).

Hello,

Ok, I followed the advice of Alan Cox and looked up "Solar Designer" on 
google.

So, my questions (to Solar Designer) are:

1. what exactly are the details of the setuid race Alan Cox is referring
to above? I have 0 (zero) doubts in the validity of Alan's words and
always trust him, but it doesn't imply that I always understand him, and
so would appreciate a clarification.

2. are you sure that there is no way to fix the above race without
preventing even the superuser access to /proc/<PID>/mem of 
any process?

More specifically (to save you time re-reading this thread) I am referring 
to the code in fs/proc/base.c:mem_read():

        if (!MAY_PTRACE(task) || !may_ptrace_attach(task))
                return -ESRCH;

and also the same check on return from access_process_vm(), which I 
suggested to relax a little, by allowing CAP_SYS_PTRACE user (or 
CAP_SYS_RAWIO perhaps?) to access /proc/<PID>/mem of any task without any 
hindrance.

Btw, the second check looks like an obvious race to me. I.e. if this
condition can change between the check in the beginning of mem_read() and
return from access_process_vm() then what is to stop it from changing just
after this second check and return from mem_read()?

Therefore, the code in mem_read() does look broken to me, but instead of 
"re-inventing the wheel" and trying to fix it "from scratch" I would like 
to get a fair knowledge of the history/reasons for these changes, please.

Kind regards
Tigran

-
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/

-
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/