[cisstrd]

And I appreciate it, I don't doubt that OS X isn't the best choice, and for sure there is some kind of trade-off going on, most likely, yet I assume a lot of it also has to do with how those products are used, meaning an inexperienced users fall into the pitfalls of maybe any system, while an experienced user will use the product rather differently?

Since you are a security researcher, aren't a lot of people of "your breed" using Macs as well?

As for the OS X security track record I don't claim to be incredibly well versed in that regard, thank you for the insight. But the piece doesn't primarily talk about security flaws, rather about systemic risks in using any sort of proprietary software whatsoever, especially by "evil" corporations like Microsoft and Apple (it might not say that directly, but that's how I conceived it) which I think is far over-emphasized.

[nickpsecurity]

"Since you are a security researcher, aren't a lot of people of "your breed" using Macs as well?"

I use Linux, BSD's, and custom systems. From what I've gathered, the people using Mac's do it for usability and apps more than anything. The Mac OS is pretty, well-designed components for GUI/desktop on top of a hybrid between a microkernel and UNIX (BSD). Let's ignore their bad choice of microkernel. The real benefit is you get a desktop with comparable usability to Windows, you can pull out command line for full power of the UNIX underneath, it's overall more reliable/consistent than Linux on desktop side, and there's plenty of apps from vendors who target Windows + Mac but not Linux.

So, that's the overall value equation. A UNIXy OS with many apps and nice interface. I considered attempting to secure its foundation, Darwin, at one point but it's a hodgepodge of crap thrown together. Clever way to get a system out the door for Jobs back in the NEXT days. Not so good later on when one is improving foundations. :)

Note: Addressing your other point in a new comment as I can never remember length restriction.

[bch]

> The Mac OS is pretty, well-designed components for GUI/desktop on top of a hybrid between a microkernel and UNIX (BSD). Let's ignore their bad choice of microkernel.

Is it necessary to ignore the microkernel choice? Isn't MacOS X -not- microkernel, even though (or "because") it uses an old version of Mach? [0][1][2]

[0] https://en.wikipedia.org/wiki/Mach_%28kernel%29

[1] http://www.roughlydrafted.com/0506.mk1.html

[2] https://www.youtube.com/watch?v=8RwlEZ88rKM&t=445

[nickpsecurity]

Mach was a terrible microkernel because it tried to do too much. Good examples for you to look up are QNX, L4 (esp OKL4), EROS, and Minix 3. These all get stuff done more reliably, securely, and faster than Mach. That they've built so much into the Mach model means anything you do to improve security or performance has to fight with its inherent weaknesses.

So, Mach is its own discussion of failure in and of itself. There was also a history... Trusted Mach, Distributed TMach, DTOS... of trying and failing to secure Mach using high-assurance methods. The security improvements in new Mac OS's, esp sandboxing and such, were actually recommended with that old research in mind. They realized the foundation wasn't going to be secured as it never worked in the past. So, they went for decomposition and isolation schemes for apps themselves plus IIRC integration of TrustedBSD mechanisms.

[bch]

I appreciate the links. I'm still perplexed though -- isn't the Mach component of MacOS X not at all a microkerel? Are you saying "it sort of is", or "it certainly is" ?

The promises of microkernels seem extremely attractive to me, but we know that the promise of simplicity doesn't come for free (witness Hurd[0]). There were versions of Mach that were high-profile (i.e.: media/developer attention) microkernels, but I thought the Mach in MacOS X really was simply "not a microkernel". Interested to hear more about this if you've got illuminating info.

[0] https://www.gnu.org/software/hurd/hurd.html

[nickpsecurity]

Mach is a microkernel but Darwin is not. This is what Mac OS X runs on:

https://en.wikipedia.org/wiki/XNU

https://en.wikipedia.org/wiki/Darwin_%28operating_system%29

XNU is monolothic software since it (a) merges code like BSD in with the microkernel and (b) has a ton of kernel-mode code in violation of microkernel principles. It can be said that microkernels can still benefit monolithic heaps of kernel code by providing a consistent, simple way for pieces to internally communicate. Windows has a microkernel inside of it for that reason IIRC.

"witness Hurd[0]"

Hurd is another failure. So many microkernels, including commercial deployments, have happened during the lifetime of that project not achieving its goals. Situations like Mach and Hurd are why people think microkernels suck. You have to see good examples. Did you ever use a Windows 95/98 box back in the day? Remember how it would choke trying to do anything intensive or concurrent? Check out what microkernel-based BeOS does on older hardware in my UNIX alternatives list:

https://news.ycombinator.com/item?id=10957020

Tannenbaum has a nice paper describing the two biggest problems plus different styles of handling them. It includes the microkernel techniques that are reason we like them for robustness.

http://www.minix3.org/docs/jorrit-herder/computer-may06.pdf

On capability-security site, KeyKOS had fine-grained isolation, protected communication, and checkpointing of app's state in case of failures. Shapiro's successor, EROS, is described in this document along with many key principles to high-assurance reliability and security that good work must leverage:

http://flint.cs.yale.edu/cs428/doc/eros-ieee.pdf

Note: Unfortunately, project is dead as FOSS contributors had little interest and he got poached by Microsoft. Did deliver a more secure networking stack and GUI system on top of a prototype kernel. COYOTOS project papers have some lessons learned, too.

[nickpsecurity]

"rather about systemic risks in using any sort of proprietary software whatsoever"

There actually are under common distribution and licensing models. I used to think Stallman et al were vastly overstating the situation. These days, I think he was mostly right based on what companies did & do. I'll give you a few data points for your consideration.

1. Privacy/security. Proprietary vs open-source is false dilemma given first, secure system was a proprietary system (Burroughs B5000) that shared source with users. You can share source for vetting, local builds, or whatever while charging for it. Yet, most software comes as a binary where devious things are easily hidden. Many easily prevented 0-days and backdoors (esp undocumented FTP or SSH) have been found in proprietary systems over time. Even firewalls per Grimes' regular assessments. People are running out of room trying to find all the places Windows 10 is tracking users. They can't even turn them off. Leads to next risk.

2. Control. This is really most important. A fully, OSS product lets you use it however you choose. A proprietary licensed product, esp if not perpetual, can arbitrarily change how your product is allowed to be used later down the line. They can legally shut you out of certain benefits. This is getting common with app stores, DRM restrictions, games. I used to get games I could use permanently. Now, I often have to get online to access profile for even single-player games. The vendor, despite protest of users, plans to take service down after some time to force us to buy more expensive stuff. They also put ads in there because we can't turn them off so why not. Control is very important and many major companies are abusing the fact that "our" devices/software are actually "their" devices/software we merely get licensed to use only how they want to. Future-proofed against this with FOSS.

3. Lockin. Proprietary vendors often use obscure storage formats or communication protocols to make it hard to extract your data. They use custom API's to reduce portability. The result is that, after you build on them enough, you're effectively stuck with them since a move would cost exhorbitantly more than just paying an obscene licensing fee again. Such lock-in lets companies effectively stop innovating and benefiting their customers while their customers are powerless to do anything since the business, its apps, or its data just go bye-bye. Open storage, protocols, and API's can mitigate this but they (esp Microsoft) have nasty habits of subverting those with extensions or undefined behavior. So, FOSS clearly has a win here as you can just use the source itself to get off the platform if you want or pay someone to improve it.

4. One company I know specializes in proprietary hardware they sell but with FOSS software. In a discussion, the lead engineer told me he refused to use proprietary in their products since he was burned badly by one. The issue is the right to inspect code to debug and fix the dependency. You don't have it with proprietary & the vendor might not give a shit once you've already paid them. He (and FOSS advocates) argue that the complexity & bug-rate with modern software make it imperative to have source to ensure anything you build on it works correctly now and later.

5. Legal risks. No secret that licensing is often a minefield where compliance can be tricky. Vendors make it hard unnecessarily & overcharge. Business Software Alliance represents them telling customers' employees they'll get bounties if they snitch about instances of this then suing the crap out of small and mid-sized firms that didn't pay Microsoft, Oracle, etc enough. Big firms stay patenting software stuff, even cut n paste is Microsoft's haha, that they use to sue any competition or even users cloning to escape a bad platform. Recently, Oracle's argument that API's are copywritten essentially says nobody can make an alternative that's backward compatible and Oracle's users should be legally forced to be stuck with them. All these risks, except patent suits, are nonexistent when you use FOSS software. Plus, working with predatory companies seems wrong on principle.

6. Abandonware/bankruptcies. Company gets tired of supporting something or goes out of business. They can force you to keep buying something while basically not updating or supporting it any more. Lots of games and old apps in that status that are still fun/useful today but have to use emulators due to no source or legal restrictions. Impossible with FOSS as someone can roll up sleeves and code.

So, there's some datapoints that have and currently are burning up companies that invested in proprietary instead of open solutions. The major FOSS techs from 10 years ago still exist in some updated form with many others in development. Clearly systemic risk on one side of the equation with very little on other. What you think? :)