ptrace and setuid problem

[Tom Horsley]

No, not a new security hole (exactly), more of a philosophy
question:

If I exec a setuid program under ptrace, I can read the image via
PEEKDATA requests. Could (or should) that be considered a security
hole?  Come to think of it, should any executable with no read
access (setuid or not) be debuggable where ptrace will be able to
peek at it even without read access?

Looking at most of the linux systems I've used, setuid program are
typically installed as execute only, not readable. The /proc files
are also readable only by the appropriate user, etc. Every attempt
seems to be made to prevent anyone from doing anything other than
just executing the program.  (This seems to have gotten more and
more draconian over time - at one time I couldn't readlink()
the exe file, but I could read the maps file and find the
executable name listed in there, thus digging up the exe name via
a backdoor.  In newer kernels I see I can't read the maps file
either, so as a debugger developer I'm reduced to digging through
the argv vector to try and deduce which program is running).

Wouldn't it make more sense to have setuid programs simply not be
ptraced?  Is there good cause to add a new even more draconian
restriction?  Perhaps put ptraced setuid programs in a special
state where no peek/poke stuff works (maybe all requests return
EPERM so the debugger can tell it has hit a setuid wall) and the
debugger has only two options: PTRACE_DETACH or PTRACE_KILL? If
detach was selected, the program could continue to execute as a
setuid program (since we know the debugger wasn't able to diddle
the program in any way, that should still be secure).

If a patch to implement this were to be generated, what would be
the odds of it being accepted? :-).

(I could try and watch any discussion this generates on the
archives, but probably best to CC me in any replies as I am not
subscribed to lkml).

Disclosure: My ulterior motive for bringing this up as a security
issue is to get the "detach and let run as setuid" feature to work
so I don't have to go to all the trouble of figuring out how to
patch the program to re-exec() itself so I can then detach and let
it run normally as a setuid program - which is what I really want
to happen in my debugger :-).

P.S. Sorry if this shows up twice, but I sent it originally about
three days ago and have yet to see it show up, so I'm trying
again from a different account.

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