This is the result of a recent change in OS X 10.11, called System Integrity Protection.
It's a big step in the wrong direction [opinion], especially because it does nothing to verify "integrity". It prevents changes to the System directory by conventional means (and injection into system processes).
If malware were to figure out a way to disable SIP from userland, it could install itself in such a way that nothing short of disabling SIP could uninstall it.
But that's the thing, you can't disable SIP from userland. It can only be disabled when booted into recovery mode. So yes, it absolutely does verify integrity, because it makes it so malware cannot embed itself into the system. Your last sentence there is 100% pure grade A FUD. You may as well just say "every security measure is bullshit, because if malware were to figure a way around it, then it wouldn't work". It's a meaningless statement.
It's a boot argument to the kernel, stored in NVRAM. These arguments are normally mutable. Apple had to write code to prevent modifying said arguments. Said code can have flaws.
But lets say you don't find a vulnerability in SIP userland detection, and instead find a kernel exploit to get around the protection:
If malware were to figure a way around it, then even antivirus software can't uninstall it. Only Apple can. It's not FUD.
Don't be alarmist, worst case a cleaning tool would have to be run from recovery mode, but nuke and pave is usually the recommended cause of action if you get a infected with a rootkit.
SIP holes will be found, and Apple will patch them just like other security flaws.
There are a few exceptions but generally you can stay one or two versions behind. While Apple annoyingly don't state how long they support OS releases, they currently ship security patches for 10.8 and 10.9. The last patch for Lion was just before the 10.10 release.
It is FUD since it is not impossible to make these changes, it's just (intentionally) more difficult than casually supplying a sudo password. Anyone can detect signature changes in a system directory and anyone can boot to a recovery volume (either the default Apple one or one provided by an anti-virus company, if desired) to make whatever corrective change they want.
This is absolutely FUD. Even if you're correct and malware finds a way around it, then it obviously doesn't work, which means antivirus software could use the same mechanism to kick out the malware.
If you have some malware that actually needs to modify system files, that still significantly ups the ante. Sure, if you have a kernel exploit, you can do it, but currently malware does not need any exploits to take over a system if it can convince a user to download and type in their password to install - Gatekeeper is one mechanism to prevent this, but I've personally been served multiple ads offering malware with a valid Developer ID signature, so it's tricky... (though I don't know how aggressively Apple is working to revoke their certificates). The difference in skill required between just writing an installer disguised as legitimate software on one hand, and continuously coming up with working exploits on the other, is pretty huge. And in any case, the easiest-to-exploit OS X privilege escalation vulnerabilities are things like rootpipe that don't compromise the kernel.
However, this argument falls down a little if malware doesn't actually need to modify system files, which it doesn't for most typical evil stuff I can think of.
It wouldn't be undeletable, it would just involve booting into a recovery volume (either the automatic Apple recovery partition or a user supplied volume).
Since all System locations will now be signed (as part of the move to SIP), it means that the basic Apple recovery partition will be able to purge any such malware by a simple signature verification.
Does it actually do that? I haven't heard of it... But just reinstalling the OS accomplishes the same, slightly less quickly. Of course, if the malware is nasty enough, it might modify user settings to make a program run automatically, e.g., by adding it as a startup item, which, unless that OS reinstall included a patch, could then exploit the bug again and reinstall itself to the system locations. Not much Apple can do about that.
Does booting an alternate OS still work to get around it, or have Apple thought of that route and somehow blocked it too?
(I have limited experience with OS X - only briefly played around with driver development and bootloaders in the 10.4 era with osx86 - and I did have to boot from the DVD a few times when I made the system unbootable.)
This raises the question, what good is root if it's not really root anymore?
This has been the plan for several years. I remember seeing block diagrams for GlobalPlatform's Trusted Execution Environment[1] that were based on the idea of the "Rich OS" (OSX, Linux, etc) being able to run more or less normally, with something that isn't really a hypervisor providing the "secure"/"trusted" environment.
The idea is that a combination of a SecureBoot-style trusted boot sequence and technologies like Intel's SGX instructions to create an area that is protected from everything else, root included.
Ever since (heavily controlled) iOS was accepted by the tech crowd as a replacement for a proper General Purpose Computer, we've been slowly loosing more and more control. At least there seems to be workarounds for this particular OSX "feature". It is incredibly important to stop this trend now; it will be a lot harder to work around these restrictions when it gets hardware support.
> Does booting an alternate OS still work to get around it, or have Apple thought of that route and somehow blocked it too?
It's easier than that. It's just a kernel argument to disable it. Simply add "rootless=0" to your boot-args and you have control of your machine back.
I'm running the 10.11 beta and I've already had to disable rootless because I like to have /usr/local as a symlink to somewhere else and by default the rootless configuration prevents writes to /usr. :-/
Apple has stated that the "rootless=0" boot argument to disable System Integrity Protection is temporary and will be gone in the GM version of El Capitan. Allowing this route to disable the feature would defeat the entire purpose of it.
Source? They said in the WWDC session (http://asciiwwdc.com/2015/sessions/706) that the process to disable rootless may change during the beta, but didn't say that it won't be possible in the GM.
They know that rootless will break some applications/drivers, plus some types of development may need it disabled.
You are allowed to write to /usr/local. But making /usr/local itself into a symlink requires writing to /usr which is prohibited. So I was screwed but for the normal case it should work fine.
There is a supported option to disable SIP from recovery mode, so there's no need to get around it per se. (Recovery mode because it would be hard to impossible to verify the user's intent when malware that already has root privileges is running...)
>nothing short of disabling SIP could uninstall it
At the very least, the OS needs to be reinstalled from an off-disk source, and that's assuming you haven't been hit by something sophisticated enough to put itself in firmware. We're fast approaching an era where you need to trash the hardware. You should never trust an OS install that was ever compromised, and making it more difficult to do so is a good thing in my book.
Tell me about it. I recently bit the bullet and upgraded to 10.10 after waiting for quite a while. Man... Firefox has been crashing regularly since then, the Mail.app will also crash every now and then, and to top it off, the system itself has crashed twice on me over the past... two weeks. Sigh
It's a big step in the wrong direction [opinion], especially because it does nothing to verify "integrity". It prevents changes to the System directory by conventional means (and injection into system processes).
If malware were to figure out a way to disable SIP from userland, it could install itself in such a way that nothing short of disabling SIP could uninstall it.