New feature coming in Fedora 17 will allow users to disable ptrace and sys_ptrace access on an SELinux system. http://danwalsh.livejournal.com/49336.html Talks about this and demonstrates it. strace id strace: ptrace(PTRACE_TRACEME, ...): Permission denied [Exit 1] It has been suggested that we should probably print something about SELinux potentially blocking this access. Something like strace id strace: ptrace(PTRACE_TRACEME, ...): Permission denied SELinux may be blocking this access, check the deny_ptrace boolean [Exit 1]
When ptrace(PTRACE_TRACEME) is rejected by kernel with EACCES, it is not clear what kind of kernel policy is in effect that actually denied access. It might be SELinux as well as any other security policy. From upstream PoV, I am not sure it is quite correct to give users such explicit hint to check SELinux controls. I suppose the diagnostics should be more universal. BTW, current code from strace.git HEAD prints the following diagnostics in that case: $ strace id strace: test_ptrace_setoptions_for_all: PTRACE_TRACEME doesn't work: Permission denied strace: test_ptrace_setoptions_for_all: unexpected exit status 1 $ echo $? 1
Following up on a hallway conversation I had with Dan, I'd argue for a downstream patch that adds a message that actually tells the user what to do (and hints at the risks, plus gives them a link for more information). Within Fedora it's reasonable to expect that SELinux is the security module in effect. I notice that Ubuntu has a different ptrace protection mechanism: https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection So I think there's an argument for upstream strace to have a hook for handling ptrace failure, which downstream distributors will want to implement their own versions of based on their OS. For Fedora, perhaps it could be something like this message (after checking the status of deny_ptrace): $ strace id strace: ptrace(PTRACE_TRACEME, ...): 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. (or similar text) [Having said that, should strace get its own domain? Unlike gdb, isn't strace just reading from the other process?] Hope this is helpful
Created attachment 559121 [details] This patch would implement what Dave Suggested. ./strace id strace: ptrace(PTRACE_TRACEME, ...): 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 the following shell command as root: setsebool deny_ptrace 0 See https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace for more information. [Exit 1]
Created attachment 559123 [details] Updated patch to handle strace -p as well as strace id This patch also requires that you update that you run autoconf Since this is checking for the deny_ptrace boolean being turned on, it is a good chance that it is correct, of course it can still generate false message if you say try to connect to a process running at a different UID. IE Turning off the boolean would still not allow you to ptrace.
(In reply to comment #4) > Created attachment 559123 [details] > Updated patch to handle strace -p as well as strace id strace.git HEAD needs different hooks as well as an option to build without selinux even when -lselinux is available, so I've prepared another commit: http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=ldv/selinux Please give it a try (switch to branch ldv/selinux, then run autoreconf && ./configure && make). > This patch also requires that you update that you run autoconf > > Since this is checking for the deny_ptrace boolean being turned on, it is a > good chance that it is correct, of course it can still generate false message > if you say try to connect to a process running at a different UID. IE Turning > off the boolean would still not allow you to ptrace. strace from HEAD does internal tests using fork() followed by ptrace(PTRACE_TRACEME), so hooking new diagnostics there should have no risk of false messages.
> strace.git HEAD needs different hooks as well as an option to build without > selinux even when -lselinux is available, so I've prepared another commit: > > http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=ldv/selinux + "See https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace for more information.\n"); This message gives user a Fedora-specific URL. I think upstream should be distro-agnostic.
(In reply to comment #6) > > strace.git HEAD needs different hooks as well as an option to build without > > selinux even when -lselinux is available, so I've prepared another commit: > > > > http://strace.git.sourceforge.net/git/gitweb.cgi?p=strace/strace;a=commitdiff;h=ldv/selinux > > + "See > https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace for more > information.\n"); > > This message gives user a Fedora-specific URL. > I think upstream should be distro-agnostic. Well, the "deny_ptrace" SELinux boolean is also quite Fedora-specific; more than that, it is specific to certain versions of Fedora SELinux policy. So, if the check is based on 'security_get_boolean_active("deny_ptrace") == 1', then there is no harm to give a Fedora-specific URL. Another idea: change --without-selinux in the above mentioned commit to --with-fedora-selinux, to make it really distro-agnostic.
This bug blocks Bug 802072 SELinux deny_ptrace: Do not restrict PTRACE_TRACEME but it seems that should be the other way around. Normal strace on a process the user starts should work by allowing PTRACE_TRACEME as normal, it is strace -p that uses PTRACE_ATTACH on an arbitrary process that you might want to block with selinux.
Mark that is the intention. We want to allow strace /usr/bin/foobar and block strace -p 3344 gdb /usr/bin/foobar and block gdb -p 1324
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
If PTRACE_TRACEME is not denied, do we still need to patch strace? JFYI, strace starting with commit v4.7-15-g26bc060 tries to use PTRACE_SEIZE by default. A restrictive SELinux policy might force strace to use old PTRACE_TRACEME interface, though.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.