Bug 786878
Summary: | We need to patch gdb for potential SELinux breakage. | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Walsh <dwalsh> | |
Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 17 | CC: | belegdol, dmalcolm, dvlasenk, eparis, jan.kratochvil, jreiser, kees, kevin, ldv, onestero, pmuldoon, roland, schwab, scottt.tw, sdsmall, sergiodj, tbzatek, tromey | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | gdb-7.3.1-48.fc15 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | 786876 | |||
: | 802072 (view as bug list) | Environment: | ||
Last Closed: | 2012-03-21 18:42:41 UTC | Type: | --- | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 786876 | |||
Bug Blocks: | 802072 |
Description
Daniel Walsh
2012-02-02 16:21:28 UTC
following up on our hallway chat, why not make it easy for the user and tell them exactly what to do. Ideally gdb itself should do the equivalent of "getsebool deny_ptrace" and if it's enabled, it can write something like this: Attaching to process 6570 ptrace: Permission denied. The SELinux boolean "deny_ptrace" is enabled, preventing arbitrary processes from snooping on each other (as a layered defense against intruders). You can disable this protection by running this shell command: setsebool deny_ptrace 0 as root. See https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace for more information. (gdb) (or somesuch text). FWIW, if you have sudo, you can actually do this directly from gdb: (gdb) shell sudo setsebool deny_ptrace 0 For upstream gdb, it's probably worthwhile doing something like having gdb call a Python hook when ptrace fails. Then we can have the user-friendly message or automagic behavior implemented in Fedora-specific ways in Python code. Dan, as I explained in your blog (I posted a followup today, you're right that ABRT is not affected, but DrKonqi is), this default breaks KDE's DrKonqi crash handler and is thus just plain unacceptable. Kevin open a different bugzilla for that on selinux-policy. We will need to write policy for DrKongi and allow it the access but prevent unconfined_t transition to this domain. It's not possible. DrKonqi is run from unconfined_t. Then as discussed on the livejournal, DrKonqi will need to disable the boolean when it gets installed. Phil, would you wrap attach (not just the command but also -p etc.) by Python or should I go non-Python way? We cannot override GDB inbuilt commands yet (though there are plans to do this eventually). So "attach" would have to remain an internal GDB command, untouched by Python. Could use "pattach", though I am not sure this is desirable There would be needed some other kind of hook anyway. You need to catch also: $ gdb <file> <pid> $ gdb -p <pid> Well given that command overriding is unlikely to be done before this becomes an issue on Fedora, I think we probably need a native C GDB solution. Also I think Ubuntu has some restrictions in effect from ptrace. Is it ABI-compliant to read "/selinux/booleans/deny_ptrace" instead of spawning "getsebool deny_ptrace"? Using security_get_boolean_active instead. [patch 1/3] attach-fail-reasons: Reshuffle code http://sourceware.org/ml/gdb-patches/2012-03/msg00169.html [patch 2/3] attach-fail-reasons: Say more than ptrace: Operation not permitted. http://sourceware.org/ml/gdb-patches/2012-03/msg00170.html [patch 3/3] attach-fail-reasons: SELinux deny_ptrace http://sourceware.org/ml/gdb-patches/2012-03/msg00171.html gdb-7.4.50.20120120-28.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gdb-7.4.50.20120120-28.fc17 While I was patching it into GDB I realized - why do you forbid PTRACE_TRACEME? This is OK - PTRACE_ATTACH: $ gdb -p 707 Attaching to process 707 warning: the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0 ptrace: Permission denied. But why to forbid PTRACE_TRACEME? $ gdb true (gdb) run Starting program: /usr/bin/true Cannot create process: Permission denied warning: the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0 During startup program exited with code 127. deny_ptrace would be more acceptable if PTRACE_TRACEME is allowed. And should it go into FSF GDB or is this "deny_ptrace" feature still being cooked and it should be rather kept only as a Fedora patch? Lets open a separate bug for this(kernel) customer yesterday. Dan, again in english? Jan is right, it would make more sense to allow one to trace their children. But such permissions will require a kernel change. I assume that's what you meant. We can probably steal the similar logic from YAMA... Note to self for implementation: Requires a new policy capability so we check old ptrace permission if policy doesn't yet support the new PTRACE_CHILD permission. The allow/deny unknown work is only adequate when restricting thing further (aka new permission) instead of changing the semantics of or reducing the scope of current permissions. Package gdb-7.4.50.20120120-28.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gdb-7.4.50.20120120-28.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3126/gdb-7.4.50.20120120-28.fc17 then log in and leave karma (feedback). (In reply to comment #17) > Dan, again in english? > > Jan is right, it would make more sense to allow one to trace their children. > But such permissions will require a kernel change. I assume that's what you > meant. We can probably steal the similar logic from YAMA... > > Note to self for implementation: > Requires a new policy capability so we check old ptrace permission if policy > doesn't yet support the new PTRACE_CHILD permission. The allow/deny unknown > work is only adequate when restricting thing further (aka new permission) > instead of changing the semantics of or reducing the scope of current > permissions. It would be significantly simpler to just change the existing selinux_ptrace_traceme() hook to use a different permission (if the corresponding policy capability was defined) so that it can be distinguished in policy. That seems to be all they need, not the general ability to PTRACE_ATTACH to an arbitrary descendant. gdb-7.4.50.20120120-29.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gdb-7.4.50.20120120-29.fc17 gdb cannot set a breakpoint in its *own* child process! gdb must be allowed to do this; the policy is broken. Broken in gdb-7.4.50.20120120-29.fc17.x86_64 which is greater than claimed Fixed in gdb-7.4.50.20120120-28.fc17 with selinux-policy-3.10.0-95.fc17.noarch selinux-policy-targeted-3.10.0-95.fc17.noarch kernel-3.3.0-0.rc5.git3.1.fc17.x86_64 $ gdb hello GNU gdb (GDB) Fedora (7.4.50.20120120-29.fc17) (gdb) b main Breakpoint 1 at 0x4004e0: file hello.c, line 5. (gdb) run Starting program: /home/jreiser/hello Cannot create process: Permission denied During startup program exited with code 127. (gdb) q $ Raw Audit Messages type=AVC msg=audit(1331310642.672:71): avc: denied { ptrace } for pid=1297 comm="gdb" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1331310642.672:71): arch=x86_64 syscall=ptrace per=40000 success=no exit=EACCES a0=0 a1=0 a2=0 a3=0 items=0 ppid=1295 pid=1297 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm=gdb exe=/usr/bin/gdb subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Sorry, there was packaging mistake affecting only Koji, not local builds. Try gdb-7.4.50.20120120-30.fc17. Starting program: /home/jkratoch/redhat/hello Cannot create process: Permission denied warning: the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0 During startup program exited with code 127. (gdb) q kernel-3.3.0-0.rc6.git0.2.fc17.x86_64 If you complain that spawning new processes (instead of attaching) should be permitted this is a kernel problem, not this Bug. gdb-7.4.50.20120120-30.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gdb-7.4.50.20120120-30.fc17 Package gdb-7.4.50.20120120-30.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gdb-7.4.50.20120120-30.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3496/gdb-7.4.50.20120120-30.fc17 then log in and leave karma (feedback). $ rpm -q gdb gdb-7.4.50.20120120-31.fc17.x86_64 $ gdb gnumeric GNU gdb (GDB) Fedora (7.4.50.20120120-31.fc17) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/gnumeric...Reading symbols from /usr/lib/debug/usr/bin/gnumeric-1.11.2.debug...done. done. (gdb) run Starting program: /usr/bin/gnumeric Cannot create process: Brak dostępu warning: the SELinux boolean 'deny_ptrace' is enabled, you can disable this process attach protection by: (gdb) shell sudo setsebool deny_ptrace=0 During startup program exited with code 127. (gdb) Is it really the intended behaviour that gdb does not work in its default configuration? I also had deny_ptrace turned on by default for F-17 installation. I expected it is some testing of deny_ptrace to be turned off for GA. But technically it is offtopic for this Bug. Well we are hoping to have a kernel fix to allow a process to ptrace its children by default. The boolean will be turned on by default in the beta. It was accidently turned off in the alpha. gdb-7.3.50.20110722-13.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/gdb-7.3.50.20110722-13.fc16 gdb-7.4.50.20120120-32.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gdb-7.4.50.20120120-32.fc17 gdb-7.3.1-48.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/gdb-7.3.1-48.fc15 gdb-7.4.50.20120120-32.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. gdb-7.3.50.20110722-13.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. gdb-7.3.1-48.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. Please consider just _actually using_ Yama, instead of inventing a new way to do the same thing. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-.6.git;a=tree;f=security/yama;hb=HEAD This is how all the upstream projects expect to define ptrace relationships. It's done programmatically through prctl(PR_SET_PTRACER, ...). Without Yama, you'll have to reinvent the logic for no reason. http://lists.fedoraproject.org/pipermail/devel/2012-April/165796.html |