From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21410 invoked by alias); 3 Apr 2002 15:52:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21380 invoked from network); 3 Apr 2002 15:52:31 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 3 Apr 2002 15:52:31 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g33FqUm04939; Wed, 3 Apr 2002 09:52:30 -0600 Date: Wed, 03 Apr 2002 07:52:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200204031552.g33FqUm04939@duracef.shout.net> To: gdb@sources.redhat.com, kewarken@qnx.com Subject: Re: gdb and suid binaries - security? X-SW-Source: 2002-04/txt/msg00016.txt.bz2 This is a well known case. The kernel does a permission check at the time that the parent starts tracing the child (or Process A attaches to Process B). In the linux kernel, this check is in "ptrace_attach" in file kernel/ptrace.c. > Oddly enough I've noticed that this actually fails on both FreeBSD > and Linux but it almost seems to be some mechanism outside of gdb. > Does anyone know how this works? gdb is an unprivileged process. It just calls ptrace() a lot, or it reads and write /proc a lot. It's the kernel's job to deny gdb from attaching to privileged processes, just as it's the kernel's job to deny "cat > /etc/passwd" for unprivileged users. Michael C