RE: unable to attach to setuid program that as reverted it privilege

["Reynolds, Brandon" <brandon dot reynolds at lmco dot com>]

Tavis,

Obviously there are security risks involved; however, sometimes the
choice is between giving users root and allowing them to debug a process
with some extended capabilities.

Michael,

I agree wholeheartedly with you that it would be good to have some fine
grained control over things.  I wonder if that is what
prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) is supposed to do?  See "man 2 prctl"
for details.

I can't seem to reproduce results however with either tweaking the proc
file or calling prctl().  What kernel are you running?

-Brandon

-----Original Message-----
From: Tavis Ormandy [mailto:taviso@sdf.lonestar.org] 
Sent: Monday, April 14, 2008 9:46 AM
To: Reynolds, Brandon
Cc: pottmi@gmail.com; gdb@sourceware.org
Subject: Re: unable to attach to setuid program that as reverted it
privilege

On Mon, Apr 14, 2008 at 09:32:34AM -0400, Reynolds, Brandon wrote:
> > This is documented as allowing core files to be created for setuid
> > programs.  What I am using it for is to allow gdb run as a non-root
> > user to connect to setuid programs that have _permanently_ given up
> > their root privilege.  Without suid_dumpable enabled, gdb will fail
> > with a EPERM error even tho the target program is no longer running
as
> > root and can not reacquire root privilege ( a good default behavior
).
> 

Consider the suid root ping program, it aquires a SOCK_RAW socket, and
then drops privileges. If you were allowed to attach to it after it has
dropped privileges, you could wait for it to get the socket, then
PTRACE_ATTACH and PTRACE_POKE in your own code, which now has a raw
socket that it can use for any purpose it likes.

Obviously, this cannot be permitted (i'm sure some operating systems get
it wrong though :-)).

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------