
“Rootless” feature in El Capitan means DTrace no longer works - Cieplak
http://apple.stackexchange.com/a/208185
======
Cieplak
I didn't mean to be alarmist by posting this. I actually think SIP is probably
a good thing. I just wanted to raise awareness so folks don't get bitten by
it. I ran into this issue earlier trying to benchmark IO performance of my
software on bare metal rather than in vagrant. Unfortunately, it seems iotop
and iosnoop are broken unless I press this big red button that only experts
can press to disable SIP, when all I want to do is a little system profiling.
Maybe Activity Monitor has a scripting API I don't know about. I'm just kind
of annoyed by this, I would rather dual boot into Linux than having to restart
into Recovery Mode to get basic IO profiling. I can understand that DTrace
could be a privilege escalation risk, but maybe Apple has an official
recommendation for how to properly use DTrace or an analogous API. `iostat`
doesn't cut it because I'm looking at a specific process which is run under my
user. I'm not using dtrace to reverse engineer system libraries. (I think)
Apple already compiles dtrace with hooks so that it won't trace specific
processes to mitigate reverse engineering, which I can deal with. But hell,
even `htop` is totally wrong now as I compare it to what Activity Monitor is
showing.

~~~
kogir
You only need to boot into recovery mode once to change the setting, not every
time. Turning it off isn't a big deal, and you have a valid reason to do so.

Most users never need any of the functionality restricted by SIP, and will
benefit from the greater security it provides. Every step forward in exploit
mitigation is usually a tradeoff - NX broke some programs. ASLR broke others.
SIP is no different.

~~~
Cieplak
Personally I think I like having SIP. It means a webkit zero-day can't as
easily load a kernel extension or edit firmware. I guess DTrace works by
putting probes into other processes, so even though it is only "reading"
system information, it's only able to instrument the data it reads in the
first place by mutating other running processes.

------
yifanlu
Okay, there's many problems with this post.

First, most people do not need to use dtrace. Especially on system processes.
They claim that this is bad for security researchers because they can't
monitor the system anymore and they showed a screenshot of dtrace not working
even with SIP "disabled". However, from the screenshot, we see that SIP is, in
fact not disabled because of this line

> System Integrity Protection status: enabled.

You can see here [http://internals.exposed/blog/dtrace-vs-
sip.html](http://internals.exposed/blog/dtrace-vs-sip.html) that with SIP
properly disabled, you can run dtrace on system processes. Yes, it's confusing
that it says "DTrace restrictions: disabled", when it should say "some dtrace
restrictions".

Also, no security researcher worth their salt would be stopped by this (and no
"bad guy" would be stopped from debugging either). In fact, dtrace is only a
convenience and one tool in a toolbox; you have VMs with kernel level
debuggers. You have object code analysis. You have wireshark and so on. If
Apple can't stop people from jailbreaking their iphones (where hardware
enforces the lockdown), they won't stop people from debugging their PC's
kernel.

Basically, SIP is good for users (the "Ultimately this means that Apple has
replaced the 'be all and end all' security barrier of the root password, with
the 'be all and end all' SIP protection mechanism." argument is the same as
"we shouldn't outlaw guns because people will find other ways of killing each
other") since it makes compromising a system all that harder. If it hinders
ANY security research, I question the skills of that researcher.

~~~
aftbit
He did make one point that you've failed to address:

> Disabling SIP tells all software, from both the bad guys and Apple, that
> this system is being watched. No more watching the watchers.

You're right, there are other tools. However, this definitely increases the
barrier to entry for performing analysis of software.

~~~
yifanlu
I don't get that point. "Normal" users won't (and shouldn't) disable SIP.
Those who do need to for security research won't really care that Apple knows
they're poking into the system (when you disclose a vulnerability, they'll
know who you are) and for the very paranoid, you can disable network or block
connections to Apple or etc.

It's a strawman argument because for security researchers, there is never a
problem of "we can't let them know we're looking". There's also no evidence
that Apple phones home the status either.

And re:"barrier of entry". Who should we be protecting? Amateur security
researchers or mass users? As an amateur security researcher I'd happily allow
my job to be 10x harder if it makes users even 2x safer.

~~~
Buge
We might want to hide our activity from malware. The malware might delete
itself as soon as SIP is disabled.

~~~
ryannielsen
If you're looking to hide your activity from malware, you should be incredibly
excited by SIP. With SIP enabled, you have _more_ protection from malware
introspecting other processes or monitoring activity on the system. Hell, if
you're a researcher building tools to detect and analyze OS X malware, you'd
likely _benefit_ from SIP by opting-in your tools to SIP's restrictions.
(Tangential example: Chrome is taking this step; Canary is currently SIP
restricted.)

Malware can only introspect SIP-protected activity by employing kernel
exploits. If malware can compromise the kernel, it's game over. You're not
going to hide anything, ever.

If anything, it sounds like you want SIP's purview expanded to encompass more
of OS X.

------
zw
[Really easy to enable.]([http://internals.exposed/blog/dtrace-vs-
sip.html](http://internals.exposed/blog/dtrace-vs-sip.html))

But, hey, sure. Don't let that stop you from getting angry. Merry Christmas.

There should be a bingo card for this thread. "#doomed" "taking away
freedoms". Free space is "What Steve would've done".

~~~
michael_h
TFA addressed that. For the regular folk, this will be fine. For security
researchers, it's a big flag that will let malware change its behavior.

He also posted a handy screenshot that shows Dtrace not working on some
binaries even with SIP completely off.

~~~
HappyTypist
SIP is turned on in the screenshot.

> System Integrity Protection status: enabled.

~~~
michael_h
Ack, you're correct. SIP is on, but everything is disabled.

------
Cieplak
" _I think the answer speaks plainly and precisely to a good part of the
question, which is how the experience of using a shell as root will change.
Sudo is now pseudo sudo._ "

-– sas08

[http://apple.stackexchange.com/questions/193368/what-is-
the-...](http://apple.stackexchange.com/questions/193368/what-is-the-rootless-
feature-in-el-capitan-really/208185#comment251806_208185)

------
exabrial
I think SIP in general is a good idea, but gives Apple the opportunity to
abuse their market position, which historically they have.

On a side note, I've been developing on a Mac for years. Is there any Linux
distributions with a UI and directory utilities as polished as OSX?

~~~
on_and_off
[http://elementary.io/](http://elementary.io/) &
[http://www.linuxmint.com/](http://www.linuxmint.com/) are the two distros I
often hear about. I have not tested them myself though, I might someday if OsX
becomes too closed-up to be useful for my needs.

Even with all the random problems I had with the first version of El Capitan,
I doubt that a linux distro can rival the polish of OsX though. Of course, I
would love to be wrong.

------
meesterdude
Yet another move by apple to take away your control over your own machine.
Some parts of the filesystem become off limits, even as root. But installers
have access! That's kinda nuts.

Obviously: most users wont care or notice. But when you combine this with
other changes apple has made; it's clear where they're taking OS X: just as
unfriendly to tinkering and exploration as their hardware.

~~~
ryannielsen
> Some parts of the filesystem become off limits, even as root. But installers
> have access!

Point of clarification: only Apple-signed installers can modify system paths.
(c.f. [https://support.apple.com/en-us/HT204899](https://support.apple.com/en-
us/HT204899)) All other installers are subject to SIP restrictions.

And Apple only added a few simple steps for people eager to tinker: reboot and
disable SIP. Or reboot into the installer for the other OS with which you
prefer to tinker. Or create a VM with an experimental OS. Frankly, most of
those steps existed before SIP.

Most users shouldn't care or notice, and will benefit from increased
protection. People who want to tinker will (and can and should!) tinker.

------
aftbit
This and other developments around computer security and usability "for the
everyman" worry me for two reasons.

First, they're taking away the "hard edges" from the system and helping create
a generation of computer users who don't know how to tinker, how the inner
bits work, or how to take responsibility for their own actions. If they
download a virus, that's somehow Apple's fault for not developing a secure
enough system. If they use an emoticon in their only root account password
with FileVault enabled, it's Apple's fault that they are now locked out of
their machine.

Second, and more worryingly, this works towards the "appification" of
computers. The user's freedom to run whatever software they want on the
desktop is a powerful check against the walled garden "app store" model where
a central group (i.e. Apple) is responsible for determining what you're
allowed to do. That's bad for innovation and freedom.

The famous Apple 1984 ad feels more ironic every year.

~~~
pdkl95
Exactly. Apple is responsible for a huge loss of freedom in the War On General
Purpose Computing. This "appification" is _exactly_ what Cory Doctorow was
talking about in his famous essay[1]. We are already beginning to see some of
the nastier effects that we warned about[2] with, for example, John Deere's
attempt to retain ownership[3].

Apologists will complain that you can turn of SIP (or jailbreak your phone) to
regain control over your computer, but that isn't possible for most people.
Installing certain types of software went from "run the installer" to "follow
these complicated technical instructions" (or worse).

What I find more worrying is how easily technical people are fooled into
supporting this loss of freedom. Scream "security" and suddenly it's ok for
Apple to have root but not the supposed "owner" of the device? Of course, they
know how to disable the restrictions or install a jailbreak, so these problems
don't apply to the technological priesthood - it's normal people that have to
live with the restrictions.

Well, this hubris will not last - once Apple can starts using the new Trusted
Computing[4] features on new CPUs (such as SGX[5]), good luck regaining
control.

It would be nice if more people actually bothered thinking about long-term
consequences.

[1]
[http://boingboing.net/2012/01/10/lockdown.html](http://boingboing.net/2012/01/10/lockdown.html)

[2]
[https://www.youtube.com/watch?v=nypRYpVKc5Y](https://www.youtube.com/watch?v=nypRYpVKc5Y)

[3] [http://www.wired.com/2015/04/dmca-ownership-john-
deere/](http://www.wired.com/2015/04/dmca-ownership-john-deere/)

[4] one example:
[http://i.imgur.com/rjbzWyB.jpg](http://i.imgur.com/rjbzWyB.jpg)

[5]
[https://news.ycombinator.com/item?id=10754170](https://news.ycombinator.com/item?id=10754170)

~~~
ryannielsen
> Apple can [sic] starts using the new Trusted Computing[4] features on new
> CPUs (such as SGX[5]), good luck regaining control.

It seems the apocalypse came to pass a while back, with the Secure Enclave in
Apple's A7 processors.

> Of course, they know how to disable the restrictions or install a jailbreak,
> so these problems don't apply to the technological priesthood - it's normal
> people that have to live with the restrictions.

Here's the funny thing: normal people _benefit_ from those restrictions.
Without them, their devices – the ones you insist they should own – would
quickly become someone else's: the attacker's. It _would_ be awesome if people
started thinking about long-term consequences.

Honest question: do you hate root? Should all processes run with equal
privileges? Does the kernel have an evil and undesired permissions level?

~~~
userbinator
_do you hate root? Should all processes run with equal privileges? Does the
kernel have an evil and undesired permissions level?_

The key difference here is that root is well known to be the all-powerful
user, the one that really owns the system, while SIP is Apple's attempt at
removing the power that root should have.

~~~
chc
Given that Apple could have actually taken away root's power if they wanted
to, it seems kind of inaccurate to call this an attempt to do so. They have
given the user the option to have root on or off with a default of "off." They
didn't attempt to disable root and fail.

I understand your concerns about taking away user power, but this doesn't seem
to be that. The user still has the power to do the same things, they just have
to decide that they want it. You could just as well say that not making the
system files world-writable takes away the user's power, but in fact it's just
locked behind a door that the user has the power to open.

------
lelf
> _DTrace is similar to ptrace /strace in Linux_

No. It's 10000× more. [http://www.dtracebook.com/](http://www.dtracebook.com/)

------
derefr
For everyone complaining about Apple taking away something or other that was
important to you: please consider what SIP/"rootless" actually is.

What Apple have done here is not anything like the "dev mode" switch on
Android, or the Gatekeeper "signed code only" setting. This change _isn 't_
another of the litany of changes that expand the gap between developers and
regular users. This change is, instead, about creating a different _model_ for
how OS modifications happen.

For a while now, there have been two copies of OSX on a Mac: the "regular use"
one, and the "recovery" partition. Both are full OSX, and can run arbitrary
OSX software; it's basically like having a copy of the Linux Live CD you
installed Linux from copied to your disk alongside the actual Linux install.

With SIP/rootless, Apple has effectively made it so that instead of the
actively-running copy of the OS ever modifying _itself_ , the OS will only
ever modify _the other copy of the OS_ on-disk. So you need to have the
recovery OS running to modify the files of the "regular use" OS†; and you need
to be running in the "regular use" OS to apply a _recovery update_ (i.e. an
update to the recovery OS.)

The procedures for _getting around_ SIP by disabling it and then running
things, are as arcane as they are because they're quite divorced from the
_reason_ for SIP. SIP isn't supposed to be a system for blocking and
whitelisting kernel-hooking apps; it's a mechanism for making the OS into
something more like CoreOS or the Wii's IOS: a system with two separate on-
disc OS images, where at least one is always a Last-Known-Good configuration,
and where you reboot into the "spare" one when you want to replace the
previously-"active" one. You never fiddle with the "in-use" OS image; you
consider it locked.

You still have root on the computer. You just have to be in OS-A to do root-
level things to OS-B, and vice-versa.

An analogy: remember how it was impossible (and still is, on some OSes) to
resize the boot partition you're running from, requiring you to instead boot
from a USB to do that? That's basically what is happening here, except without
the need for the USB. You can't do stupid things to the active OS; it's
locked. You modify the OS by mounting it as a slave from another copy of the
OS.

\---

† I'm not actually sure how system updates from the "regular use" side work
with SIP enabled. They could have a special exception in the SIP
infrastructure, but I doubt it.

I would guess they work like iOS updates do: the update package gets
downloaded by the running OS, and then a UEFI flag is written to tell the OS
to reboot into the recovery OS in "update" mode. The recovery OS then unpacks
and shoves the update, and reboots back.

If there _is_ an exception in SIP for the Installer, it was likely considered
more as an optimization over the above process—something to avoid making OSX
feel like Windows XP, rebooting five times to get anything done.

~~~
X-Istence
> I'm not actually sure how system updates from the "regular use" side work
> with SIP enabled. They could have a special exception in the SIP
> infrastructure, but I doubt it.

Apple Signed (with Apple's special key) Installers are allowed to modify
system paths, including the current running system to install updaets.

~~~
derefr
Interesting. I'm guessing that only gets used by minor "feature" updates (to
e.g. Webkit, or iTunes), and not the full "OSX Update 10.11.x" releases.

My suspicion is for anecdotal reasons: I recently Internet-restored my MBP.
This pushed it back down to OSX 10.11.0, so it had quite a few OS point-
updates to go install. But before I let it do any of those, I enabled
FileVault2 and let it finish encrypting. I then had the "pleasure" of watching
this sequence of events repeat itself several times, a sequence of events
which had never occurred before El Capitan:

1\. The OS asks to restart to install an update.

2\. The OS reboots and sits at the (UEFI?) drive-unlock pretend-login screen
until I enter my password.

3\. The OS boots into something that looks like my "regular use" OS—the Menu
Bar appears, the cursor appears and starts working, and my regular wallpaper
is rendered—but the Finder doesn't start, nor do any of my account's Startup
Items or LaunchAgents (not sure about global LaunchDaemons.)

4\. The screen (still with HID cursor control enabled!) gets covered in a
fullscreen _window_ (not a fullscreened app taking up a Space; wrong
transition effect) that has the appearance of a big black screen with an Apple
logo and a progress bar. You know, like the boot screen, or iOS's update mode,
or a Mac's UEFI firmware update mode. But it's definitely just an app, running
within whatever instance of OSX this is.

5\. Having completed the update, the computer reboots again, I enter my drive-
unlock password again, and I'm back into my regular-use session.

\---

Previous to El Capitan, OSX Update packages would trigger a much simpler
process, equivalent to the process Windows currently goes through:

1\. Ask the user to "reboot";

2\. instead of rebooting, stop all userland processes and enter a single-
user/maintenance runlevel;

3\. run some special privileged (kext?) code that installs/unpacks/shoves the
update and directly manipulates the framebuffer to render a progress bar;

4\. actually reboot.

\---

It wouldn't make sense to change from the old process to the current one if it
was just for the sake of putting the system into an SIP-disabled mode. Like
you said, Apple-signed installers can flout SIP restrictions.

It only makes sense to add the extra reboot to the process if you're rebooting
into the recovery OS, because having the recovery OS do the work _is itself
the goal_ , rather than just an idea born out of necessity.

If you're wondering about the "still has my wallpaper" part, though: it's not
unprecedented for the recovery OS to be "fed" data from the regular-use OS, so
that there's a continuity of control when you reboot into the recovery OS. For
example, the recovery OS will receive a copy of any wi-fi AP keys you entered
into the System keychain in the regular-use OS, so that you can re-install OSX
even if you don't remember your wi-fi password.

(I say "will receive a copy" instead of "accesses" because it gets these even
if the regular-use OS is sitting in the FileVault2 "locked" state from the
recovery OS's perspective—or has already been blown away entirely—where it
couldn't possibly just mount the volume to read your System keychain. It seems
to be more that the regular-use OS will push a copy of these thing over into
the recovery OS when you update them.)

------
hartator
I don't really see the big deal here, you ~just have to disable SIP to make
dtrace works again fully, right?

I guess it can be an issue if in the future Apple decides to no longer allow
us to officially disable SIP.

------
coldtea
> _If SIP was about security they could have educated users about root -
> instead they removed it._

Yeah, because this would work....

------
Daishiman
Once again, Stallman was right: in the name of security, manufacturers proceed
in the war against general computing.

~~~
pas
He is right, but the market is still king. If you can't give efficiency to
users by your more general computing platform than the walled-restricted one,
then you'll be left resourceless, hence powerless, thus unable to defend your
ideas any more.

Stallman is right, but he doesn't seem to be the solution.

------
djsumdog
Glad I dropped MacOS. Looks like today, I can't even build a hackintosh
without first disabling SIP.

Lion pissed me off when they removed Spaces/Expose with that Mission Control
rubbish. It's only gone downhill with each new release.

------
TechnoJoe
The author of that post should have included references.

1\. If it does not work (dr race), then why is it still present?

2\. He states root is gone, but not gone; LOL please explain or give us a link
with more details.

3\. Even if this is true, it's not going to slow us down much. We will
continue with business, as usual.

