OS X 10.11 El Capitan: the Ars Technica review

Really, this is the first time in several years that iOS and OS X have felt like they’ve gotten (and needed) the same amount of attention from Apple – both get to spend a release in the slow lane as Apple puts its marketing muscle behind newer platforms like the Apple Watch and the new Apple TV. Like iOS 9 (and Mountain Lion, and Snow Leopard), El Capitan is about refinement. Yosemite’s big statement was “This is what OS X looks like now.” El Capitan’s is a relatively meek “Hey, I have a couple neat tricks to show you.”

[q]At this point I want you to pause and ask yourself a question. Do you really depend on TotalFinder workflows so much that you want to possibly lower your system security? Frankly, I’m going to stop active TotalFinder development because it is not economically viable to continue development for a small group of users who decide to disable SIP. Also it is likely that in the next OS release after El Capitan TotalFinder won’t work at all. It is increasingly more difficult to reverse-engineer Finder as new parts are being written in Swift. Also operating system security hardening will probaly continue in future. Those are good things, but you will have to let TotalFinder go at some point anyway. Maybe for you the day is today. Bite the bullet and move on. I have prepared a list of TotalFinder alternatives here.

Same goes for Total Terminal, he is giving up on it and recommending you use iTerm2.

I actually liked that whole look, muted down a bit more from the original Aqua but still better than the overly flat renditions that now seem to populate modern UIs as some hipster homage to retro looks.

I actually liked that whole look, muted down a bit more from the original Aqua but still better than the overly flat renditions that now seem to populate modern UIs as some hipster homage to retro looks.

Thoroughly agree. With the exception of the brushed metal, that can be quite tacky at times, I still cherish the look and feel of the earlier iterations of Mac OS X and look with dismay to the current offerings of all vendors, including OSS ones.

Sadly, my beloved KDE is slowly walking on to that direction with Plasma 5 as well…

And to add insult to the injury, GNOME which is known for its – some would say, rather extreme – minimalism, is looking more vibrant and tridimensional than all of the mainstream desktops combined… That’s saying something!

If I understand correctly in Windows Administrator doesn’t have all the permissions any more. What was it again Windows Installer has more permissions ?

More and more we’re seeing OS vendors treating owners like the enemy.

I do see value in sandboxing on most platforms. However it’s extremely disappointing when a vendor designs it to block out the administrator such that the administrator would need to turn it off to access one’s own system. Security features should be designed to empower administrators, not to handcuff us.

I do see value in sandboxing on most platforms. However it’s extremely disappointing when a vendor designs it to block out the administrator such that the administrator would need to turn it off to access one’s own system. Security features should be designed to empower administrators, not to handcuff us.

And it can be argued that the owners bring this on themselves. They simply can’t be trusted with an “open” system. And in the end, that corrupted open system doesn’t just harm the user anymore, but everyone else by fostering botnets and all sorts of other crime enabling behavior.

What would be nice in the next version is more granularity than a simple, huge ON/OFF switch. That way the administrator can selectively open trusted path ways in to their system.

And it can be argued that the owners bring this on themselves. They simply can’t be trusted with an “open” system. And in the end, that corrupted open system doesn’t just harm the user anymore, but everyone else by fostering botnets and all sorts of other crime enabling behavior. [/q]

I understand your point. We might point at windows and say “hey, the reason for malware is because users aren’t trustworthy”. However I think this view lacks context. The reason windows users have had so many problems with security is because apps are assumed to have the same trust level as the user and malware takes advantage of this. In other words, the windows security model doesn’t do enough to recognize the fact that apps are less trustworthy than users, and consequently we as users have very little protection from malicious apps – it has little to do with our trustworthiness. MS repeated this mistake over and over again with win32s/activex.

When we look at other platforms that were designed with sandboxing, even those that are not forcefully restricted, we do not witness anything like the malware epidemic that has tainted MS windows.

[q]What would be nice in the next version is more granularity than a simple, huge ON/OFF switch. That way the administrator can selectively open trusted path ways in to their system.

I agree, however my gut tells me that apple’s intention is to rope owners out and keep these privileges for itself. For all we know, the next version may disable the on/off switch entirely.

It’s not (only) about treating owners like the enemey. They also are trying to force their “application stores” model down your throats.

Example: recent Windows and OS X versions support sandboxing for store programs only. i.e. if you download a random program for the store, it is fully sandboxed and can barely touch any user files, not to mention system files.

However, if you download a random program from the WWW and run it, it will be run _unconstrained_ in both OS X and Windows. When you need sandboxing most, that is, when you download a random binary from the Internet for a quick thing, current OSes decide its best to do that without the sandbox.

It’s not (only) about treating owners like the enemey. They also are trying to force their “application stores” model down your throats.

Example: recent Windows and OS X versions support sandboxing for store programs only. i.e. if you download a random program for the store, it is fully sandboxed and can barely touch any user files, not to mention system files.

However, if you download a random program from the WWW and run it, it will be run _unconstrained_ in both OS X and Windows. When you need sandboxing most, that is, when you download a random binary from the Internet for a quick thing, current OSes decide its best to do that without the sandbox.

I think you are right on all counts. Sandboxing is extremely valuable for running untrusted apps, ie those downloaded from the web. Unfortunately venders are more interested in making security contingent on their locked down business models rather than enabling all users to benefit from better security.

I would love to encourage the adoption of sandboxes, but not at the expense of freedom. One of my biggest gripes with “metro” is microsoft’s greed. Until I have the absolute freedom to buy/sell/control indy applications outside of Microsoft’s store, I won’t even consider touching that platform. Even if MS reduced their 33% cut to 0%, I’m still totally opposed to them controlling the distribution of my apps, which is tyrannical in and of itself.

Example: recent Windows and OS X versions support sandboxing for store programs only. i.e. if you download a random program for the store, it is fully sandboxed and can barely touch any user files, not to mention system files.

However, if you download a random program from the WWW and run it, it will be run _unconstrained_ in both OS X and Windows. [/q]

That is not true for either Windows or OSX…

Applications distributed in the Windows and Mac app stores must (with rare exceptions) be sandboxed, you cannot distributed a non-sandboxed application in either store. That doesn’t mean you cannot create such a sandboxed app and distribute it yourself…

You can do so with either OS – the APIs used to achieve sandboxing are not reserved for store apps and never have been. They are just not required. In practice this means there is little or no motivation for developers to use them, so few if any do. But you can most certainly make a sandboxed app and distribute it yourself.

On OSX this is completely transparent, a sandboxed app is exactly like any other app, just sandboxed. There are in fact quite a few sandboxed apps distributed outside of the Mac app store.

On Windows it is a little more hairy, because you can only (without resorting to hackery) sandbox metro apps, and non-store metro apps require sideloading, which is itself restricted. But that restriction doesn’t have anything to do with sandboxing, and sideloading such an app (if you have the means to) will work just fine.

[q]When you need sandboxing most, that is, when you download a random binary from the Internet for a quick thing, current OSes decide its best to do that without the sandbox.

No. The developer decides that, not the OS. If the app was built to be sandboxed it will be, otherwise it won’t be. The OS isn’t deciding anything.

Unfortunately neither OS can sandbox applications that were not built with the intention of running that way, at least not yet.

No. The developer decides that, not the OS. If the app was built to be sandboxed it will be, otherwise it won’t be. The OS isn’t deciding anything. [/q]

Disagree, the app developer has absolutely no say if the platform/OS wants to enforce sandboxing of resources (ie internet/NFS/documents/webcam/email/etc).

[q]Unfortunately neither OS can sandbox applications that were not built with the intention of running that way, at least not yet.

I’ll concede there can be some major usability problems adding sandboxing after the fact. UAC was a disaster and it didn’t even have fine grained permissions that we’d see on IOS/android. An alternative that may fare better for pre-existing applications that weren’t designed for sandboxing may be an access redirection policy rather than outright denial. Here is 3rd party software that implements this sandbox model.

Disagree, the app developer has absolutely no say if the platform/OS wants to enforce sandboxing of resources (ie internet/NFS/documents/webcam/email/etc).

True. But I was referring to how things actually are on Windows and OS X, not how they could be. Right now sandboxing is opt in and off by default for “vanilla” binaries on both platforms (metro apps not withstanding). If the app doesn’t opt in to sandboxing it won’t be sandboxed…

ps. I realize that UAC prompts are a form of sandboxing, but Im not counting things that allow interactive control – Im talking about SIP and AppContainer type sandboxing, that is based on trust chains.

You can do so with either OS – the APIs used to achieve sandboxing are not reserved for store apps and never have been. [/q] Ok, please tell me how to do this. In the OS X world, I need a developer ID just to read information about how to do it, and the visible free documentation suggests the need of a developer certificate. In Windows, I need either an Enterprise edition or distributing my program via the Store for it to be sandboxed.

I will be happy to try anything you suggest.

in fact quite a few sandboxed apps distributed outside of the Mac app store.

Examples please!

But that restriction doesn’t have anything to do with sandboxing, and sideloading such an app (if you have the means to) will work just fine.

…. So it turns out that I cannot use sandboxing for non-Store programs.

[q]No. The developer decides that, not the OS. If the app was built to be sandboxed it will be, otherwise it won’t be. The OS isn’t deciding anything.

Yeah, the OS developers are deciding that. Why is the sandbox availability tied to the Store at all? It would make more sense to disable the Sandbox only for Store programs, for which a revocation process at least exists (but that would be even more tying and annoying, too). And most annoyingly, why is it a developer decision, specially for OS X where sandboxed apps have almost no API changes at all?

A Sandbox that the developer controls is useful for catching bugs, but useless for any actual sandboxing purposes.

Ok, please tell me how to do this. In the OS X world, I need a developer ID just to read information about how to do it, and the visible free documentation suggests the need of a developer certificate. In Windows, I need either an Enterprise edition or distributing my program via the Store for it to be sandboxed.

I will be happy to try anything you suggest. [/q]

Yes, on OSX your need a developer certificate (i.e. you have to signup and pay $99/year) if you want things to work transparently. Such a certificate will also allow you to distribute in the app store, but you do not have to – it is perfectly acceptable to self distribute.

And yes, for Windows you need an EE edition in order to sideload a sandboxed app.

Because metro apps cannot be sideloaded by most people, and you cannot create non-metro apps (yet) using AppContainer, it is effectively a non-starter if you want to actually distribute to normal people. My point was not that there are no limitations, I was just pointing out that the limitations are not related to sandboxing itself (i.e. the limitation is that MS doesn’t allow self distribution of metro apps – sandboxed or not)…

Examples please!

Chromium makes extensive use of the sandboxing facilities on OSX – but it would not qualify as a store app because it is not fully sandboxed:

You can run anything in a sandbox on OSX using sandbox-exec. Of course it may not work right, but if you just want to experiment with it you can use that as a on-demand wrapper. Signing with entitlements basically does the same thing, it just makes it explicit and required – it won’t run outside of the sandbox.

And most annoyingly, why is it a developer decision, specially for OS X where sandboxed apps have almost no API changes at all?

I don’t know where you got that idea from. Sandboxed applications have extensive restrictions on what they are allowed to do. The “no API changes al all” claim is pretty bogus – most apps require significant changes. That is partly why the Mac App store is slowly dying, the sandboxed-only app restriction makes it impossible to publish anything remotely complex…

[q]A Sandbox that the developer controls is useful for catching bugs, but useless for any actual sandboxing purposes.

Didn’t say it was perfect, or even good… its frankly a pain in the ass as far as I am concerned… Just saying that is how it works.

Ironically, this might be a huge boon for crackers. With $1MILLION+ bounties for iOS, some people will be very pleased with the idea that once SIP is cracked, the malware will be almost impossible to remove.

Ironically, this might be a huge boon for crackers. With $1MILLION+ bounties for iOS, some people will be very pleased with the idea that once SIP is cracked, the malware will be almost impossible to remove.

(Is SIP already on iOS?)

Actually if you read those two pages in the review (highly recommended as they are very interesting and full of technical details), you can currently disable the feature by booting into recovery mode.

The scary part is that it only really takes two minor changes from Apple to completely lock down OS X: 1) restrict bootloader, 2) remove that you can disable it in recovery mode.

I don’t know if iOS has SIP installed, but here it doesn’t matter as much since there’s no way to execute a ‘sudo’ without jailbreaking it first.

So young Thomas, are we at this dystopian vision that you had almost 5 years ago when you claimed that Apple would turned OS X into a walled garden? or once again are we going to hear you talk about how it is ‘one more release away’?

So young Thomas, are we at this dystopian vision that you had almost 5 years ago when you claimed that Apple would turned OS X into a walled garden? or once again are we going to hear you talk about how it is ‘one more release away’?

Well, with features like SIP and Gatekeeper We are 1-click away from the walled garden, it’s just an on/off switch. I mean, all the “infrastructure” predicted by Thom is there, he was (kind of) right.