"As you have guessed by now I am some kind of allergic to this... those idealistic over-simplifications... drawing everything in black and white..."
I avoid oversimplifications, too. Yet, most of what the author wrote was proven by precedent. Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform. Gotta be a kernel by kernel and distro by distro judgment on that. Rest seems accurate.
"Some of the OS X users I know are incredible technology-orientated and privacy concerned people, should I draw the conclusion they are being overly naive by not using OpenBSD for everything?"
The conclusion is that they prefer to use OS X. That simple. Far as its security, it's made by a company that spent a long time lying to its users that they were immune to malware because Mac's were just inherently secure. They added lots of mitigations sometimes 10 years behind Windows and UNIX per one firm. I recall one vulnerability where an administrative service required a username and password for log-in but didn't check it against database. If you entered any password, you got in.
Such a history of absolutely, terrible security plus deception of customers means Apple products shouldn't be trusted for security by default. Any "privacy concerned people" using it are making a foolish mistake or intentionally trading away privacy for some other benefit.
Now, what you just saw me do was the evidence-based approach to these things. Helps cut through the noise nicely.
"Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform."
That's fair. FWIW I wasn't trying to focus on Linux in my post. I'm grateful for Linux and the volunteers that contribute to it, both the apps and the security work. The work everyone is doing on FOSS lifts all boats. And you're right of course, not all Linux distros are created equal when it comes to security. And my anti-privacy, anti-security sentiment was more pointed at proprietary software, i.e. a lot of iOS apps.
> Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform. Gotta be a kernel by kernel and distro by distro judgment on that.
That caught my eye as well; lumping Linux in with Windows or even OSX is insulting in the extreme on the privacy front and only slightly less on the security front. To be sure, the focus on many Linux distros is not security at the forefront, and there are some that you definitely shouldn't trust if you're paranoid (those that use binary only kernel modules), but just being on Linux is a step in the right direction if you value privacy, freedom and security. Hell, can someone tell me if it's dead simple to install OpenBSD with full disk encryption? Debian has offered this for quite some time, and it's why I wipe and re-install even pre-installed Linux systems with it.
> Hell, can someone tell me if it's dead simple to install OpenBSD with full disk encryption?
Dead simple. Full disk encryption on OpenBSD is a discipline of softraid(4). One bioctl command during the install will initialize a hard disk with true full disk encryption. When I say true, I mean, no separate un-encrypted /boot partition like LVM on LUKS requires.
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.
"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.
> 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]
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.
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.
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:
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.
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:
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.
"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? :)
From what I see, this is Apple's answer to the Biba model for integrity protection that's intended to divide system up into trust levels where untrustworthy processes can't write files they shouldn't. This was in Orange Book B1-B3 & A1 class systems such as Compartmented Mode Workstations. LOMAC model, SELinux/SEBSD, Windows Integrity Control, Argus PitBull, and Trustifier all implement this scheme to protect files integrity.
Let's just say it's a technique that helps but doesn't guarantee security by far. The reason is that the check is in the kernel. That can be bypassed by a 0-day attack on the kernel or below. Trusted processes that manage it might also be hit. Less likely, the person with control over it might be conned into installing something rogue. Seems Apple uses signatures to address that to some degree. So, one tool in the security toolbox just like it was in the 90's for CMW's. Gotta protect the privileged code and interfaces to it to make sure it's not bypassed.
One advantage of Biba and similar models are that they're conceptually simple plus very efficient in storage and CPU time. I think of it as an extra check to fall back on instead of primary protection. Cost almost nothing. Hope this write-up helps in your assessment of Mac security.
I avoid oversimplifications, too. Yet, most of what the author wrote was proven by precedent. Only grip I have is calling Linux anti-security and anti-privacy given how much good work in those used the platform. Gotta be a kernel by kernel and distro by distro judgment on that. Rest seems accurate.
"Some of the OS X users I know are incredible technology-orientated and privacy concerned people, should I draw the conclusion they are being overly naive by not using OpenBSD for everything?"
The conclusion is that they prefer to use OS X. That simple. Far as its security, it's made by a company that spent a long time lying to its users that they were immune to malware because Mac's were just inherently secure. They added lots of mitigations sometimes 10 years behind Windows and UNIX per one firm. I recall one vulnerability where an administrative service required a username and password for log-in but didn't check it against database. If you entered any password, you got in.
Such a history of absolutely, terrible security plus deception of customers means Apple products shouldn't be trusted for security by default. Any "privacy concerned people" using it are making a foolish mistake or intentionally trading away privacy for some other benefit.
Now, what you just saw me do was the evidence-based approach to these things. Helps cut through the noise nicely.