Bug 802065 - permission denied for ptrace of own child by strace and gdb
permission denied for ptrace of own child by strace and gdb
Status: CLOSED DUPLICATE of bug 802072
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-10 12:12 EST by John Reiser
Modified: 2012-03-12 09:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-12 09:38:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2012-03-10 12:12:06 EST
Description of problem: By default, neither strace nor gdb can invoke a child process in tracing mode.  Before Fedora 17, ptrace attach required that the attaching process have the same UID (or 0==UID [root]) as the process being attached; and this was a reasonable restriction for security, privacy, etc.  Now in Fedora 17, by default ptrace does not work at all, not even for your own direct child [clone()] process, and this is silly.  Using ptrace on a direct child process is the major intent of debugging via strace and ptrace.  Furthermore, ptrace on your own direct child is fundamentally different from ptrace attach of a non-descendent process (even if UID matches.)  Failure to distinguish these two cases (ptrace of descendent vs. ptrace of "non-related" process) is a major blunder.


Version-Release number of selected component (if applicable):
kernel-3.3.0-0.rc5.git3.1.fc17.x86_64


How reproducible: every time


Steps to Reproduce:
1. strace /usr/bin/date
2.
3.
  
Actual results:
   strace: ptrace(PTRACE_TRACEME, ...): Permission denied
and no SELinux message, and no report in syslog [/var/log/messages]. There is a report in /var/log/audit/audit.log:
type=AVC msg=audit(1331398286.618:92): avc:  denied  { ptrace } for  pid=1494 comm="strace" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process


Expected results: list of system calls performed by /usr/bin/date, with no complaints about ptrace denied.


Additional info:
selinux-policy-targeted-3.10.0-95.fc17.noarch

Workaround: "setenforce 0" before running strace.  However, invoking setenforce requires superuser permissions, and turns off all SELinux safeguards throughout the running system.

gdb-7.4.50.20120120-31.fc17.x86_64 says: warning: the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0
and doing so does enable both gdb and strace to run normally.  But changing deny_ptrace allows *any* ptrace to succeed, even ones that were denied before Fedora 17 because of mismatching UID.  Also, changing deny_ptrace should not be required in the first place just to ptrace your own child process.
Comment 1 Josh Boyer 2012-03-12 09:38:27 EDT

*** This bug has been marked as a duplicate of bug 802072 ***

Note You need to log in before you can comment on or make changes to this bug.