Comments on: fun with process scheduling

By: Patrik

Patrik — Sat, 27 Feb 2010 22:07:26 +0000

if you can get gdb to follow children, you might as well just do a sh -c ‘sleep 60; sudo …’ and attach to the sh process

By: kees

kees — Fri, 26 Feb 2010 23:04:16 +0000

Looks like I’d need ‘set follow-fork-mode child’ ‘catch exec’ ‘catch fork’ in gdb, or this in a setuid /lib .so:
int _init(void) {
int seconds = 0;
char *str = getenv(“SLEEP”);
if (str) seconds = atoi(str);
sleep(seconds);
return 0;
}

By: kees

kees — Fri, 26 Feb 2010 22:33:33 +0000

@Thomas hunh, cool. I didn’t realize that ld.so did such careful filtering. I thought it just dropped LD_PRELOAD on the ground. Yeah, that works very nicely — jamming a sleep() in the init section of a setuid lib in /lib should work great.

@Branden I wasn’t sure if gdb would play nicely across the exec (i.e. loading the new ELF image).

By: Branden

Branden — Fri, 26 Feb 2010 19:06:36 +0000

So don’t directly spawn it, but rather spawn a shim process that drops priv’s before then invoking the setuid process. The debugger should be able to follow the process tree, remaining as root.

By: Thomas

Thomas — Fri, 26 Feb 2010 12:55:48 +0000

If you want to modify the behavior of the process to study without modifying the binary, you may be able to do this by having it use a modified .so through LD_PRELOAD or LD_LIBRARY_PATH.

Why not try writing a small lib that does just kill(getpid(),SIGSTOP) and loading it through LD_PRELOAD… ?

A little googling on “LD_PRELOAD setuid” seem to show that some checks are done by ld.so to ignore LD_PRELOAD for setuid binaries in most cases, but that it is still doable if the lib you use is installed in the right path with the right flags.

http://lists.netisland.net/archives/plug/plug-2006-05/msg00018.html

So, you’re likely to need to play a little bit to get it to work, but it would seem doable that way.

By: kees

kees — Fri, 26 Feb 2010 01:04:42 +0000

Yeah, a monster sleep or a SIGSTOP-self works, but I was hoping to do this without changing the target binary. As for ptrace, yes, that’s what gdb uses for debugging. The problem is that I cannot directly use ptrace on a setuid process. I want to examine the transition from unprivileged to privileged, and I can only do that if my debugger process has the caps for it (i.e. running as root). Which means I also can’t directly spawn it.

By: Ken Bloom

Ken Bloom — Fri, 26 Feb 2010 00:58:57 +0000

Maybe you could compile a custom version of sudo that runs kill(getpid(),SIGSTOP) on itself as the first thing it does, thereby giving you time all the time in the world to attach to the process and run kill -CONT when you’re ready.

By: Branden

Branden — Thu, 25 Feb 2010 21:28:26 +0000

With ptrace(2), you can have a child process stop upon calling exec(2). Essentially, it starts up in the stopped state. Perhaps you can use that somehow?

By: kees

kees — Thu, 25 Feb 2010 19:59:38 +0000

Hmm, yeah, might work, though I think it would still be a hard race — I’d need to have something spinning with a “sudo kill -STOP $(pidof sudo)”.

By: Markus Hochholdinger

Markus Hochholdinger — Thu, 25 Feb 2010 19:42:23 +0000

What’s about kill -STOP and kill -CONT?