Bug 786876 - We need to patch strace for potential SELinux breakage.
Summary: We need to patch strace for potential SELinux breakage.
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: strace
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dmitry V. Levin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 786878 802072
TreeView+ depends on / blocked
 
Reported: 2012-02-02 16:17 UTC by Daniel Walsh
Modified: 2015-02-17 14:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 786878 810973 (view as bug list)
Environment:
Last Closed: 2015-02-17 14:04:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
This patch would implement what Dave Suggested. (2.04 KB, patch)
2012-02-02 19:45 UTC, Daniel Walsh
no flags Details | Diff
Updated patch to handle strace -p as well as strace id (2.59 KB, patch)
2012-02-02 20:11 UTC, Daniel Walsh
no flags Details | Diff

Description Daniel Walsh 2012-02-02 16:17:48 UTC
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]

Comment 1 Dmitry V. Levin 2012-02-02 17:47:26 UTC
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

Comment 2 Dave Malcolm 2012-02-02 18:34:54 UTC
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

Comment 3 Daniel Walsh 2012-02-02 19:45:03 UTC
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]

Comment 4 Daniel Walsh 2012-02-02 20:11:20 UTC
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.

Comment 5 Dmitry V. Levin 2012-02-03 02:04:11 UTC
(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.

Comment 6 Denys Vlasenko 2012-02-09 16:17:59 UTC
> 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.

Comment 7 Dmitry V. Levin 2012-02-09 22:08:15 UTC
(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.

Comment 8 Mark Wielaard 2012-04-08 07:36:07 UTC
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.

Comment 9 Daniel Walsh 2012-04-09 19:14:41 UTC
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

Comment 10 Fedora Admin XMLRPC Client 2012-12-07 21:15:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Dmitry V. Levin 2012-12-07 23:12:02 UTC
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.

Comment 12 Fedora End Of Life 2013-04-03 15:50:43 UTC
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

Comment 13 Fedora End Of Life 2015-01-09 16:58:34 UTC
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.

Comment 14 Fedora End Of Life 2015-02-17 14:04:38 UTC
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.


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