Linked by Thom Holwerda on Tue 29th Sep 2015 22:52 UTC
Mac OS X

Sadly no longer written by John Siracusa, but still a good read: Ars' Max OS X El Capitan 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."

Order by: Score:
No more Total Terminal And Total Finder
by xeoron on Wed 30th Sep 2015 01:11 UTC
xeoron
Member since:
2007-03-25

To work, both use code injections, one into Finder and the other into the Terminal app, and Apple has blocked this behavior while not providing any API or extensions to more of the system.

The only way to get these apps to work, is to disable a security feature while in recovery mode. Hopefully, the developer will find another way to do them.

Reply Score: 2

galvanash Member since:
2006-01-25

Hopefully, the developer will find another way to do them.


He won't.. He gave up.

http://totalfinder.binaryage.com/system-integrity-protection

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.

Edited 2015-09-30 04:21 UTC

Reply Score: 4

Congratulations
by judgen on Wed 30th Sep 2015 04:34 UTC
judgen
Member since:
2006-07-12

Congratulations Apple for the visually ugliest OSX release to date.

Reply Score: 1

RE: Congratulations
by dazzawazza on Wed 30th Sep 2015 08:21 UTC in reply to "Congratulations"
dazzawazza Member since:
2006-09-03

Do you really think it's worse than the old "heavy brushed steel everywhere with added scan lines!" in the 10.1 days?

http://www.guidebookgallery.org/pics/gui/desktop/full/macosx101.png

Reply Score: 2

RE[2]: Congratulations
by Hank on Wed 30th Sep 2015 21:18 UTC in reply to "RE: Congratulations"
Hank Member since:
2006-02-19

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.

Reply Score: 2

RE[3]: Congratulations
by DeadFishMan on Thu 1st Oct 2015 01:15 UTC in reply to "RE[2]: Congratulations"
DeadFishMan Member since:
2006-01-09

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!

Reply Score: 2

No OpenGL updates
by moondevil on Wed 30th Sep 2015 07:06 UTC
moondevil
Member since:
2005-07-08

As expected.

Reply Score: 3

SIP (page 8 and 9)
by dpJudas on Wed 30th Sep 2015 07:43 UTC
dpJudas
Member since:
2009-12-10

Thom, your favorite iOS feature made it to OS X! You can no longer remove Mail and Chess!

Welcome to the age where you don't own the master keys to your own computer anymore!

Reply Score: 9

RE: SIP (page 8 and 9)
by Lennie on Wed 30th Sep 2015 10:57 UTC in reply to "SIP (page 8 and 9)"
Lennie Member since:
2007-09-22

Who would have thought it would ever come to that with Apple ? ;-)

I'm surprised it took them this long.

What I think is interesting is that it works in a similar way to how Linux user namespaces works (where root in a Linux container might not actually have full root privileges).

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

Edited 2015-09-30 11:03 UTC

Reply Score: 5

RE[2]: SIP (page 8 and 9)
by Alfman on Wed 30th Sep 2015 15:59 UTC in reply to "RE: SIP (page 8 and 9)"
Alfman Member since:
2011-01-28

Lennie,

Who would have thought it would ever come to that with Apple ? ;-)
I'm surprised it took them this long.
...
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.

Reply Score: 3

RE[3]: SIP (page 8 and 9)
by Lennie on Wed 30th Sep 2015 16:51 UTC in reply to "RE[2]: SIP (page 8 and 9)"
Lennie Member since:
2007-09-22

It seems to me vendors don't care much about power users, more about the average users which doesn't care how the system works.

If we go to the extreme, the average user doesn't understand software freedom, in the sense of the free software foundation, either.

Reply Score: 3

RE[3]: SIP (page 8 and 9)
by whartung on Wed 30th Sep 2015 17:09 UTC in reply to "RE[2]: SIP (page 8 and 9)"
whartung Member since:
2005-07-06


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.


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.

Reply Score: 3

RE[4]: SIP (page 8 and 9)
by Alfman on Wed 30th Sep 2015 18:39 UTC in reply to "RE[3]: SIP (page 8 and 9)"
Alfman Member since:
2011-01-28

whartung,

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.


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.


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.

Reply Score: 3

RE[3]: SIP (page 8 and 9)
by javispedro on Wed 30th Sep 2015 17:16 UTC in reply to "RE[2]: SIP (page 8 and 9)"
javispedro Member since:
2014-06-04

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

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.

Reply Score: 3

RE[4]: SIP (page 8 and 9)
by Alfman on Wed 30th Sep 2015 18:57 UTC in reply to "RE[3]: SIP (page 8 and 9)"
Alfman Member since:
2011-01-28

javispedro,

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.

Edited 2015-09-30 19:10 UTC

Reply Score: 2

RE[4]: SIP (page 8 and 9)
by galvanash on Thu 1st Oct 2015 05:03 UTC in reply to "RE[3]: SIP (page 8 and 9)"
galvanash Member since:
2006-01-25

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.


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.

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.

Reply Score: 2

RE[5]: SIP (page 8 and 9)
by Alfman on Thu 1st Oct 2015 13:20 UTC in reply to "RE[4]: SIP (page 8 and 9)"
Alfman Member since:
2011-01-28

galvanash,

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.


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

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.
http://www.sandboxie.com/

Reply Score: 2

RE[6]: SIP (page 8 and 9)
by galvanash on Thu 1st Oct 2015 21:30 UTC in reply to "RE[5]: SIP (page 8 and 9)"
galvanash Member since:
2006-01-25

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.

Reply Score: 2

RE[5]: SIP (page 8 and 9)
by javispedro on Thu 1st Oct 2015 21:53 UTC in reply to "RE[4]: SIP (page 8 and 9)"
javispedro Member since:
2014-06-04

You can do so with either OS - the APIs used to achieve sandboxing are not reserved for store apps and never have been.

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.

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.

Edited 2015-10-01 22:01 UTC

Reply Score: 1

RE[6]: SIP (page 8 and 9)
by galvanash on Thu 1st Oct 2015 23:35 UTC in reply to "RE[5]: SIP (page 8 and 9)"
galvanash Member since:
2006-01-25

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.


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.

https://developer.apple.com/osx/distribution/

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:

https://www.chromium.org/developers/design-documents/sandbox/osx-san...

Why is the sandbox availability tied to the Store at all?


Its not... As I said a few times already.

http://blog.squarelemon.com/blog/2015/02/10/os-x-sandbox-quickstart...

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

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.

Reply Score: 2

RE: SIP (page 8 and 9)
by kristoph on Wed 30th Sep 2015 14:25 UTC in reply to "SIP (page 8 and 9)"
kristoph Member since:
2006-01-01

You can disable sip, you can then remove the offending apps, and then you can re-enable sip ( or not as you wish ).

Honestly this is how it should work in iOS.

Reply Score: 2

RE[2]: SIP (page 8 and 9)
by dpJudas on Wed 30th Sep 2015 17:47 UTC in reply to "RE: SIP (page 8 and 9)"
dpJudas Member since:
2009-12-10

You can disable sip, you can then remove the offending apps, and then you can re-enable sip ( or not as you wish ).

Honestly this is how it should work in iOS.

You can't be seriously suggesting end users need to boot into recovery mode to remove apps.

My comment was a bit of a joke anyway because Thom always complains about the stock iOS apps taking up space on his home screen. We aren't there with OS X.. yet. ;)

Reply Score: 3

Comment by Kroc
by Kroc on Wed 30th Sep 2015 09:50 UTC
Kroc
Member since:
2005-11-10

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

Reply Score: 2

RE: Comment by Kroc
by dpJudas on Wed 30th Sep 2015 10:18 UTC in reply to "Comment by Kroc"
dpJudas Member since:
2009-12-10

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.

Reply Score: 3

RE[2]: Comment by Kroc
by Kroc on Wed 30th Sep 2015 12:05 UTC in reply to "RE: Comment by Kroc"
Kroc Member since:
2005-11-10

I have read the whole thing and those two pages are by far the best thing about it ;)

Reply Score: 1

RE[3]: Comment by Kroc
by dpJudas on Wed 30th Sep 2015 13:57 UTC in reply to "RE[2]: Comment by Kroc"
dpJudas Member since:
2009-12-10

I have read the whole thing and those two pages are by far the best thing about it ;)

Sorry wasn't sure if you had or not. Yes, by far the most interesting part. ;)

Reply Score: 2

Drop-dead simple exploit
by netpython on Wed 30th Sep 2015 17:42 UTC
netpython
Member since:
2005-07-06

Ars Technica also reports on a drop dead simple exploit that bypasses Gatekeeper:

http://arstechnica.co.uk/security/2015/09/drop-dead-simple-exploit-...

Reply Score: 3

Comment by kaiwai
by kaiwai on Wed 30th Sep 2015 18:10 UTC
kaiwai
Member since:
2005-07-06

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'?

Reply Score: 4

RE: Comment by kaiwai
by sergio on Thu 1st Oct 2015 05:46 UTC in reply to "Comment by kaiwai"
sergio Member since:
2005-07-06

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.

Reply Score: 3