ptrace and setuid problem

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.

Re: ptrace and setuid problem

[Andreas Schwab]

Tom Horsley <tomhorsley@adelphia.net> writes:

> If I exec a setuid program under ptrace, I can read the image via
> PEEKDATA requests.

Only CAP_SYS_PTRACE capable processes get suid/sgid semantics under
ptrace, or can attach to a privileged processes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ptrace and setuid problem

[Tom Horsley]

Andreas Schwab wrote:

>Tom Horsley <tomhorsley@adelphia.net> writes:
>
>  
>
>>If I exec a setuid program under ptrace, I can read the image via
>>PEEKDATA requests.
>>    
>>
>
>Only CAP_SYS_PTRACE capable processes get suid/sgid semantics under
>ptrace, or can attach to a privileged processes.
>
>Andreas.
>
>  
>
I realize the program under ptrace is no longer running setuid, but it 
is still running,
and the debugger can examine the process memory. With most setuid programs
being installed execute-only with no read access, isn't it a security 
problem that
I can get read access anyway (at least to the parts of the file that are 
in LOAD
segments)?

(Although I do notice that my suse 9.2 system has /usr/bin/sudo 
installed readable -
it is only my fedora core 3 system that has it execute only - just to 
pick a sample
setuid program).

Maybe setuid shouldn't even be the question, maybe the issue should be that
ptrace can read parts of program files that have no read access.