With El Capitan released, there’s one ‘feature’ that really needs to be highlighted – for better or worse.
System Integrity Protection (SIP, sometimes referred to as rootless) is a security feature of OS X El Capitan, the operating system by Apple Inc. It protects certain system processes, files and folders from being modified or tampered with by other processes even when executed by the root user or by a user with root privileges (sudo). Apple says that the root user can be a significant risk factor to the system’s security, especially on systems with a single user account on which that user is also the administrator. System Integrity Protection is enabled by default, but can be disabled.
Here’s Apple’s WWDC presentation about SIP, and here’s the Ars review’s section about it.
Limiting a user’s ability to accidentally make core system changes is a good idea, especially as this is the privilege level when installing many apps.
Most malware will get into macs because the USER lets it get there.
The concern from this is that system updates must disable this feature to install (temporarily), so if you have a bit of malware that Keeps trying to edit the root files, when it does have the opportunity to install itself, there will be no way to remove it.
It doesn’t work like that. Certain core services in OSX have their packages signed with Apple certificates that can write to SIP protected paths, i.e. software update. This does not involve disabling SIP, it is part of it’s design.
Unless the malware itself is signed with those certificates or somehow can hijack a signed process (which is what SIP is supposed to protect against primarily) it can’t write to those paths.
That said, you are right though – if something, somehow, manages to exploit/bypass this it will be a real pita to remove…
Edited 2015-10-01 10:30 UTC
As the default tech guy in the early 2000’s I had the task of manually removing the occasional virus that struck a friends computer. There is one I never figured out. I tracked down the file in windows, but I could not delete it at all.
Not in safemode. Not booting the hard drive in a known good computer. NTFS writing for linux at that time was experimental and I couldn’t find a iso live cd that had it turned on, so I wasn’t able to try that.
So yeah, sounds 99% like a good idea. But there is that 1% of me that worries that I’d need to nuke the system from orbit to clear out anything that compromised it.
Yeah. Its the only way to be sure
On second thought, If I have a nuke, and the ability to get and stay in orbit, I might as well nuke it from one of Jupiter’s moons that has already been terriformed to support life. I mean, why not.
What do you mean by “default tech guy” ? Does it mean there are non-default tech guys too?
Sure. There was my friend the computer video editor that people would ask if I was on vacation. My other friend that used to have a dos computer who knew things. This other guy that “hacked” his computer at work so he could play solitaire. Everyone has some ability.
Oh there were a few other guys that knew probably as much as I did, but were difficult to talk to because they were involved in some sketchy things. Asking them for a favor was not a good idea.
That is not how it works. Only processes that have been digitally signed with a specific key from Apple will be able to make any changes. This effectively only leaves two attack vectors for software:
1) Steal the master key from Apple. (difficulty: very very hard unless you’re NSA or something)
2) Use some kernel exploit that allows you to execute anything
Hostile software can’t wait for any opportunity since it cannot alter the patching executable (the signature would be invalid then), and it cannot attach a debugger to it either.
What personally annoys me is that Apple added certain apps (i.e. Mail.app and Chess.app) to the files and processes protected by SIP. Not that I’m against those being protected, but it kind of reveals the fact that other non-Apple apps would probably also like to be protected in the same manner.
For example lets say Safari is in the protected set but Chrome is not. This means a hacker can permanently hack Chrome while not being able to do the same to Safari. This currently creates an A and B team among apps in the latest OS X.
I hope they generalize the concept a bit more in the next iteration of OS X. Having rogue apps not be able to permanently damage other applications would be a pretty cool feature.
You forgot the import 3.
Malicious code in the boot process.
Lennie,
Indeed. However not all such code is malicious.
In the early vista days I remember two signed & legitimate tools that enabled users to install to install their own drivers in the windows kernel. This enabled users to install drivers signed by their own keys, including windows xp drivers for hardware which was no longer supported in vista. MS was displeased about this and revoked the certificates for these tools even though they would only load drivers signed by the owner’s keys.
Given Microsoft’s combative stance on user drivers, the only remaining way to install ones own self-signed drivers (short of exploiting kernel vulnerabilities that would get patched) was to use bootloader modification, which actually worked. But by this point I was sufficiently disenchanted with Microsoft’s actions against independent kernel developers that I just lost interest in windows kernel development altogether and moved to Linux, which incidentally is every bit as political but at least the devs are really welcome here.
Edited 2015-10-01 21:30 UTC
Now with secure boot and so on, I’m sure Microsoft thinks different about this. Just saying it’s all malicious. 😉
First, you have to convince Apple to sign your kernel module.
Secondly, if you have a kernel module then there is no point in breaking SIP because now you have access to *everything*. At this point you might as well just patch the kernel image at boot, maybe upload your code to some firmware, etc etc. This is a completely different attack vector than what SIP is meant to protect against.
And thirdly, as you point out yourself in your example those keys can be revoked if abused.
The point of SIP is to prevent randomly downloaded code to do whatever it wants if you were lured into giving it root access. For example I constantly allow Xamarin Studio root access each time there is an update and who knows what they are doing with it. SIP establishes an outer sandbox for what even classical desktop and console apps can do. Something that is very much needed as nobody dares to try out native apps anymore in the same way as you are willing to surf randomly around in a web browser.
dpJudas,
You don’t need to convince me, I already think application sandboxes are good. It’s when they become user sandboxes than they encroach on our freedoms. Although it sounds like SIP could be improved to be more useful, as long as it can be disabled by owners it’s not that bad either.
I completely agree with you on this. It was mainly the original comment you replied to that I commenting on.
I think the real challenge of getting sandbox tech acceptable is to find the fine balance between user control, app control and avoid the ‘user always clicks Yes’ or ‘here is a useless list of permissions this app needs’ problems.
The signed driver issue you describe is actually a really good example of the conflict between those different needs. You certainly can’t allow the app to install an unsigned driver. Asking the user is a bit problematic too because you get the “you have to click yes to the security warning” requirement from vendors – even when unreasonable. And the signed executable from Apple/Microsoft has its share of problems too. Even the web solution where some random website asks for my GPS data is a bit tricky as I can’t really know what it wants it for.
I’m ok with this as a default system state.
But don’t make this difficult to turn off in later versions. Most of the problems I have with Windows that should be 30 minutes fixes and turn into 4 hour ones, come from battling with things blocking me from making changesd due to being in use, or restricted to LocalSystem, or SFC being difficult for some reason.
Add these protections but make sure it can all be easily and securely turned off. Don’t cross the line of having the OS obnoxiously repeat “I’m sorry, I can’t let you do that”.
I totally agree with this, as long as they make it semi-easy to disable (as it is now) it’s a good thing. If they would make it impossible to disable then I’m out.
Clicking on the first link results in the “Streaming is available in Safari, and through the WWDC app” message if you happen to use anything else. Like, you know… the overwhelming majority of people.
I could go on a rant about hypocrite Apple championing openness and standards only when it’s time to criticize other companies/products but, since this one is a WWDC session, I’ll look the other way instead. 😉
RT.
They used HTTP Live Streaming for this:
https://en.wikipedia.org/wiki/HTTP_Live_Streaming
It isn’t proprietary exactly, but Apple did design it and standardize on it (before HTML5 video really caught on) – no one else has bothered yet (and probably never will).
You can just download the complete video (as opposed to the stream) by clicking on one of the download links underneath it. Its a standard mp4 file (its 400MB though).
You linked to Wikipedia and the page lists the other browsers that support it:
– Microsoft Edge
– Google Chrome
– Android browser
And the webservers:
– IIS
– nginx
– Apache
Yeah, who uses those ? 😉
Anything can serve it – its just HTTP. The protocol is nothing but a set of conventions built around m3u8 playlists and MPEG-TS segments. Its more of a clever hack than a streaming protocol…
Ohh, sorry, I didn’t expect Chrome on mobile to support something and not on desktop. That’s kinda silly.
What is annoying about HLS is that it only supports MPEG, and supposedly you can fit WebM in DASH:
https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
And DASH is already a standard (ISO):
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail….
It’s not that Chrome for mobile supports it and Chrome for desktop does not.
HLS is supported by Android media framework – the infamous Stagefright. Chrome for mobile simply hands off handling to it.
Chrome for desktop has no ability to hand off the handling to anything.
No snark on this story Thom?
I am dissapoint.
Is if you can boot to recovery, disable SIP, register an alternate key, then restart. That way you could set up the systems to let you sign your own apps (or your company).
It should be safe enough considering the hoops the need jumping through to let folks do this without compromising the premises behind it.
As a proponent of computing freedom, it’s always important to be vigilant and watch for “features” that enable manufacturers to control us rather than enabling us to control our computing devices.
Certainly I think Apple deserves credit for having a switch at all, at least in contrast to IOS, Windows RT and Metro that remove owner control entirely. That said it sounds like apple’s SIP implementation needs some more work to be useful for users who actually want to be able to control security policy on their own system rather than just turning it off.
I don’t think there’s anything objectionable to such features as long as they’re under the owner’s control. There’s a really fine line between “we’re doing this to help secure the system” and “we’re doing this to keep you out of your own system”. And as we’ve learned with Microsoft’s approach to secure boot, they might well act one way to placate the initial public uproar, and then flip flop later when the focus is gone. I hope this isn’t the case with SIP, but in the back of my mind I’m worried that this may be aimed at eventually locking down MacOS further.
Edited 2015-10-01 20:40 UTC
This isn’t that big of a deal. The singular notion of root hasn’t existed for awhile in Linux, at least (probably the same is true of the other nixs and windows). The most obvious change has been the use of macs. Attacking the problem from the ground up you have seccomp with which, if it were applied universally, you could completely remove the concept of root (there are other os’s that have been designed like this from the beginning but use a concept called capabilities; the freebsd security framework capsicum is one such implementation but this is something that had been bolted on after the fact whereas these other os’s never had the concept of root to begin with). Lastly you have namespaces where any user can be root but be limited in what they can do (with the addition of bind/”union” mounts).
The way they implemented it is new, tmk, but the idea of reducing/eliminating the power of root, has been around for awhile.
tuxroller,
This isn’t wrong and I also agree it is not a big deal. IMHO having capabilities/roles is even better than having a “root account”. If I were building a kernel, I would prefer not to hardcode special privileges for UID=0 as is done in unix. It’s actually quite limiting to have to run as root for arbitrary restrictions (such as opening a local socket<1024).
However I’d like to point out that it isn’t really the source of controversy either. In general, security features are good, however the exact same OS security features that enable owners to better control software on their system can be configured by vendors to block owners from controlling their own systems. The existence of security features is not bad, but there is potential to put them to bad use against the interests of the owners, and it is this that we have to watch out for.
> It’s actually quite limiting to have to run as root for arbitrary restrictions (such as opening a local socket<1024).
Those restrictions were put in place to promise that only someone with root access was allowed to do that, so you don’t have J. Random Undergrad starting a process named “sendmail” on the department’s minicomputer, listening on port 25, and intercepting everyone’s messages. It’s dumb in a world where network services are themselves the source of attacks, but it made good sense at the time.
tidux,
Well yes, I am aware of the special use cases that motivated the policies, but it’s still hard coding security policy into the kernel, which is kind of bad. Having capabilities is an alternative to hard coding policy into a kernel, which was the OP’s point.
Consider the influence these hard coded policies have had on unix software design. Instead of invoking a process from a restricted user from the get-go, in unix they tend to start out as root, open up all resources they’ll need up front, then and then change to a restricted user. This may be ok if a system is under a single administrative authority (ie root), but in scenario where you have different departments responsible for different daemons, it’s not really ideal to hard code a policy that requires them to start with root.
I know there are some workarounds, even for kernels that don’t support capabilities, like using inetd to open resources and then transferring the sockets to a less privileged daemon. But IMHO these design factors should be determined on their own merits rather than be mandated by kernel policy.
Your mileage may very
I may not have been clear. I absolutely think that ELIMINATING the traditional root user is a very good idea.
Macs like selinux go some way towards this, but it is very difficult to build adequate policy.
http://appleinsider.com/articles/15/09/30/os-x-el-capitan-still-exp…