28

I've found dtrace to be an invaluable tool for debugging and troubleshooting all sorts of issues, not to mention the two dozen dtrace toolkit scripts shipped by Apple as part of El Capitan.

On El Cap though, running dtrace usually results in an endless spew of errors making dtrace all but useless.

Improve this question

3 Answers 3

Reset to default
25

System Integrity Protection in 10.11 can be disabled, though it's not something you should do lightly.

You can disable SIP entirely by doing the following:

  1. Reboot your mac
  2. Hold ⌘R during reboot
  3. From the Utilities menu, run Terminal
  4. Enter the following command
csrutil disable

Alternatively you can re-enable SIP while still allowing dtrace to work by also running the following:

csrutil enable --without dtrace

Note, that when doing so you'll get the following warning:

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Once you reboot, dtrace will work as it did in Yosemite.

Improve this answer
4
  • Well done - I missed this post when answering the other thread :-) I am going to re-plug Rich's session video and blog: derflounder.wordpress.com/2015/10/01/…
    – bmike ♦
    Dec 8, 2015 at 16:51
  • 6
    This isn't quite true. With DTrace enabled via csrutil you can invoke the kernel's DTrace - but only on binaries that do not have the restricted entitlements flag. You cannot remove the restricted entitlements flag, even as root, with all of SIP turned off. This means that with DTrace enabled you can DTrace non-system binaries only. However, if a non-system binary uses a shared-lib installed in the system folders (which a lot of programs do), you can't DTrace that either. So the only way to get dtrace to work 'like it did in Yosemite' is to make a copy of all your system folders, and chroot it
    – J.J
    Dec 11, 2015 at 14:57
  • @J.J what exactly does --without-dtrace do? How would it function if all the binaries still have the restricted entitlements flag set? Do you know if --without-dtrace leaves any security hole? Thanks
    – Nick
    Mar 29, 2020 at 5:13
  • On MacOS Monteray, steps 1. and 2. should be replaced with 1. Shutdown your computer, 2. Turn it on and hold the power key, 3. Release the key once you see the startup options menu on your screen. Source
    – Ulysse BN
    Feb 22, 2022 at 14:05
6

Copy the binary to a directory that is not "restricted", for example, /tmp

csrutil disable does not work for dtruss to some degree. But as @J.J said chroot works, this inspired me.

Still I don't know why this works. It may have something to do with the "protected directories", I guess.

Here is the test:

CC@~ $ csrutil status
System Integrity Protection status: disabled.
CC@~ $ sudo dtruss /bin/echo
dtrace: failed to execute /bin/echo: dtrace cannot control executables signed with restricted entitlements
CC@~ $ cp /bin/echo /tmp
CC@~ $ sudo dtruss /tmp/echo

SYSCALL(args)        = return
thread_selfid(0x0, 0x0, 0x0)         = 46811 0
csops(0x0, 0x0, 0x7FFF51B6CA20)      = 0 0
issetugid(0x0, 0x0, 0x7FFF51B6CA20)      = 0 0
shared_region_check_np(0x7FFF51B6A918, 0x0, 0x7FFF51B6CA20)      = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF51B6BEA8, 0x7FFF51B6CA20      = 0 0
Improve this answer
1
  • Do you have a list of “restricted directories”? Or is it in the file system?
    – Franklin Yu
    Jun 14, 2020 at 3:20
2

There are cases where you can't boot into recovery mode to change the SIP mode (for example when using a Mac instance from a cloud provider).

In these cases you can still partly use dtrace. You can still trace non system executables. And if you want to trace system executables (i.e. /bin/ls) you could copy them and remove codesigning:

# trying to trace 'ls' fails if SIP is enabled
$ sudo dtruss ls -R /Applications
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute ls: (os/kern) failure

# workaround: make a copy and remove codesigning
$ cd ~
$ cp /bin/ls .
$ sudo codesign --remove-signature ./ls
$ codesign -dv ./ls #verify
./ls: code object is not signed at all

# now we can trace syscalls made by "ls"
$ sudo dtruss -t open_nocancel ~/ls -R /Applications/
...
open_nocancel("/Applications\0", 0x1100004, 0x0)                 = 4 0
...

source: https://poweruser.blog/using-dtrace-with-sip-enabled-3826a352e64b

Improve this answer
1
  • This does not seem to work on ARM-based binaries. What does your otool -h ./ls say?
    – ikaerom
    Jan 2 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .