Hacker News Reader

Hacker News

Comment by babuskov | Hacker News Reader

Full thread

babuskov

I find this comment amazing:

https://github.com/shadowsocks/shadowsocks-iOS/issues/124#is...

Even with root account, you are not in full control of your Mac - you are sandboxed by Apple.

View on HN

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.

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?

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...)

> 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. :-/

Does this break homebrew? Or does it only block writes to entries in /usr and not subdirectories like /usr/local ?

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.

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.

The supported mechanism for disabling System Integrity Protection is via the recovery partition.

Apple have recently made a few changes to how you enable/disable System Integrity Protection...

https://www.reddit.com/r/osx/comments/3hv3kk/update_on_rootl...

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.

[1] http://i.imgur.com/rjbzWyB.jpg

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.

what if some os x malware finds a way past the limitations on editing system files? the malware would become undeletable

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.

How do SIP and dtrace interact?

From https://developer.apple.com/videos/wwdc/2015/?id=706

"all dtrace probes that target a system restricted process will not be matched" (i.e. will fail unless SIP is disabled).

Not really surprising, though: Apple has been making OS X a little worse with every iteration.

I am doing my best to NOT update my OSX, every time I update it, the thing get slower, it is really annoying.

El-Cap is the fastest version yet in my experience and seems to be getting important security fixes too.

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

Try installing a fresh copy, or do some HDD/RAM checks. I have been running 10.10 since it came out (+Firefox) without any problems.

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.

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.

Unless the malware uses the backdoor/exploit then patches it out once it's inside. It has complete system control, after all.

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.

> Apple will patch them just like other security flaws

With the condition that you have to upgrade to the very latest system :)

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.

>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.

Windows 10, now OS X... and meanwhile I have installed Linux on all my workstations. Looks like big corporations are shooting themselves in the foot.

I think you have that backwards. You, as the person with physical access, is in full control as SIP can be controlled from recovery mode. Processes running as root are no longer trusted to have full access to the system. This is definitely a step in the right direction.

This is an iOS app, not a Mac app.

Yes, but from the same commenter earlier: "I want to try this api on MAC OS 10.11. I understand the reason why I need to ask apple for some permission to publish the app with this api to app store, but I can't believe that I have to ask them for permission to run this api on my development machine."

It's possible that commenter is misguided. The documentation on NETunnelProviderManager[1] says it needs the extension and that you should send an email to get it, but there's no indication as to whether there's anything stopping you from granting yourself this entitlement on a development machine (obviously Apple needs to approve it for an app on the MAS; I don't know what limitations there are for non-MAS apps in this regard).

[1] https://developer.apple.com/library/prerelease/mac/documenta...

Where by "extension" I of course meant to say "entitlement".

Wow. OSX ... it was nice knowing you.

Reply on news.ycombinator.com