[cisstrd]

I am an OpenBSD user, there is no OS I'd rather use currently (obviously) and I am sure there is no OS with a greater focus on security and clean code, the project as a whole deserves a great deal of respect and admiration for setting the bar when it comes to security, and for being the originator of great products that are used outside the boundaries of OpenBSD itself, however (with all due respect) what the author portrays here is paranoid philosophical mumbo-jumbo I'm normally used to from radical FSF-devotees.

Yes, there are NSA scandals, yes, the US government has repeatedly overstepped boundaries, yes, caution and scepticism is a very healthy and good thing, but on the other hand there are GNU/Linux distributions taking security somewhat seriously, they have to, they too work with open source code, have a lot of users, and review said code, I doubt someone is interested in your specific data, I doubt using a GNU/Linux distribution or some other BSD OS is some risk one shouldn't take, I doubt we should all have to automatically strive for an "ethical" all Free Software life or otherwise we are in risk of somehow being under totalitarian control, I doubt Apple and Microsoft are totally out to get you and by definition filled with evil backdoors the NSA uses to spy on _everyone_... I doubt they only do malicious things,... and talking about security, it's not all in the Software, a lot is in users' behaviour... not talking about him specifically, but "We are all spied on by the NSA, please like me on Instagram and follow me on Facebook for hourly updates on my life so we can join in the fight against totalitarian control"...

As you have guessed by now I am some kind of allergic to this... those idealistic over-simplifications... drawing everything in black and white...

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? I don't think so, they are just not suffering from paranoia, are pragmatic and living in the real world...

[nickpsecurity]

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

[quisquous]

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

[nickpsecurity]

Fair enough. :)

[npsimons]

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

[hamsterdam156]

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

[npsimons]

Sweet! I've been considering OpenBSD for an Internet facing server for a while, this is definitely something that makes it all that more tempting.

[nickpsecurity]

Thanks for answer as I was curious too.

[xorcist]

Fwiw, in GRUB version 2 load the cryptodisk module to enable an encrypted /boot.

[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]

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

[chris_wot]

I'm genuinely curious: what do you think of SIP on OS X? Do you think it is effective?

[nickpsecurity]

Actually, a response I just gave has important background here:

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

As I went to look up SIP, I found this at the top of the results:

https://threatpost.com/os-x-zero-day-bypasses-native-sip-pro...

So, not looking great so far. ;) Anyway, I decided to look further to find a Wikipedia article on it with what looks to be great description.

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

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.

[quisquous]

I hear what you're saying. For my part, security and privacy are very practical concerns for me...the aren't just an abstract ideal:

When my father-in-law bought a computer from Costco a year ago, it was full of malware from the start. He didn't care about the spyware--it was the constant popups, and the prompts to enter credit card info and login info that was the most worrisome. When my 'mom' sent me an IM message from her Hotmail account, claiming to be somewhere in Europe and needing emergency money, I had to call her up (she was not in Europe), get her to rotate her passwords on a bunch of accounts, work with her work IT team to investigate the security breach, etc. I've had one of my personal OpenBSD servers sucked into a DDOS zombie army (did I mention I'm a security newb?) and had to wipe the thing, rebuild, and ponder my mis-configuration sins. Security is hard enough (for me anyway) as it is without starting on a less than ideal foundation.

Criminals, for the most part, are (just) trying to steal money from people I care about...and when they're lucky enough not to lose their money, it can still cost a lot of time.

States have power over life and death, and there are plenty of examples in the US and elsewhere of bad people in government abusing their power to the detriment of relatively powerless people (and giving all the good people in government a bad name). I don't want to live in a police state, where saying the wrong thing over email can lead to bad things happening to me. We're not there yet (in the US), but we're not pointed in the right direction either. I think FOSS, secure software has a positive, important role to play. It cannot answer the larger political questions, but it can help, if only to buy us time to have the debate before the abuses get too far.

[krylon]

I tend to agree, at least partially.

There are, to me, good reasons for using OpenBSD that have little to do with security. (I don't use OpenBSD as my primary OS, but that is a different story.)

What is most important to me is that the system is relatively simple as far as configuration/administration goes, and that it has very good documentation. It seems rather spartan at first, but on the other hand that means there is no hidden magic, which I have come to appreciate.

Also, the general approach OpenBSD takes towards security does not only improve security, it tends to result in software that is more reliable in general. One does not need to be paranoid to appreciate all that.

[gkya]

I'll guess, totally uninformedly, that most PC users' data/privacy gets breached because of their use of insecure third party services and/or their insecure use of third party services. That is, their credentials get stolen, the databases of the services they use are leaked and the service is late to realise the attack, they do not sanitise input and pass it directly to the database, etc... If my guess is correct, then using OpenBSD or GNU/Linux or MSDOS won't help, the users need to be informed and educated on how to securely use the online services. We already have the infrastructure: public schools. A couple hours on a week for a semester can be spared for a personal computing security lesson.

I really doubt the actual effect of using OpenBSD or whatnot on a PC users' security. It is a clean and beautiful OS, and if I wasn't blocked by hardware (ath5k, Atheros ARBXB63 on Asus X51RL, help appreciated) I'd use it (I use FreeBSD and I love love love it), but I don't think, as a PC user, it is necessarily considerably more safe in practice than a well-built Linux distro. _Server is another story though_.

[nickpsecurity]

You are totally ignoring the malware problem that's been going on for quite some time. All those botnets with hundreds of thousands of computers started as flaws in the OS or applications. Something like OpenBSD will definitely reduce the amount of those. High-assurance security platforms that address root causes with rigorous analysis reduce it to almost nothing. Usually new attack classes discovered to breach those.

So, yes, configurations and sharing will still be a problem compromising many users. But, no, the malware problem would be greatly reduced. That everything else is built on top of that integrity guarantee makes it the most important. Then, users can choose what they share, how they configure, and so on from there. Also, systems can be designed without need to share secrets to operate. Systems can also be largely self-configuring. We've seen both in market and FOSS. So, it's common issue but not inherent.

[gkya]

My intuition was that malware attacks were less prominent nowadays. I certainly cannot and will not deny the advantage of OpenBSD in front of malware, and I also cannot and do not ignore botnets, keyloggers, various code injection attacks, etc., but I believe nowadays what's at the highest risk is what we store on others' disks, i.e. the cloud, and what the commoners do, like emailing passwords in cleartext, using clumsy inept passwords, not caring about https, not knowing that one has to block JavaScript, etc. Aren't these more easily exploitable in practice than say a stack overflow somewhere in my programs (not a rhetoric question)? Though I'm no security expert. But I know that it's easier to get the bucks of a 50-year-old first-time-internet-user who's heartly disposed to enter their Gmail password to any box with a Password: label. I know many of them. To many the URL bar is linenoise. "bank.com.hackersdomain.tk"? Some cryptic crap, I don't know what it is, it looks like my bank.

The morale is an ignorant user can easily be exploited even on OpenBSD, while a security-savvy user can secure himself even on an insecure OS. Thing is, the former is way more prominent, they're in billions. I don't dismiss advantages to secure OSs, but say that the more important problem is inept users.

[nickpsecurity]

"My intuition was that malware attacks were less prominent nowadays."

They are and they aren't. What you're seeing is a combination of economics and improvements in software quality. Economics says they focus on whatever gets them the most zombified PC's since competition drives prices of each individual PC down in black market. To get this, they target apps with most widespread use. This is why almost all 0-days were found in Windows, IE, Firefox, Java, Adobe Acrobat, etc.

Microsoft's SDL & QA tools did them a 180 on code quality. Low-hanging fruit in major apps might be drying up because so many bugs were found. Attackers shifted focus to backend databases via hits on web apps as that's new low-hanging fruit (read: shit security) with huge rewards (eg million records at once) for success. So, it's not that it's gone away so much as not as popular while low-hanging fruit exists for their purposes. Organized crime, esp targeting online banking, plus nation-states continue to find, sell, and use 0-days for malware. It's still a thing except stealthier and more targeted.

"Aren't these more easily exploitable in practice than say a stack overflow somewhere in my programs (not a rhetoric question)?"

Oh yeah. Skilled hackers look for all of that. They'll look for that kind of stuff first since it saves time.

"The morale is an ignorant user can easily be exploited even on OpenBSD"

No argument from me there.

"while a security-savvy user can secure himself even on an insecure OS"

That's been disproven by too many pentests. You can cover lots of known risks but then get hit by something inherent in poor foundation you built on. I liken it to building your castle on foundation of quicksand. Security properties work layer by layer, piece by piece, from bottom up plus interactions with other systems via protocols. I might be able to secure DOS apps but DOS's intrinsic properties might eventually do me in. See what I'm talking about?

[gkya]

I do see what you're saying and I agree completely. But maybe I'm bad at telling my point: How can a secure OS help keep me from putting my credentials into a phishing webpage? How can it prevent me from setting my Facebook/Gmail password as riley89angel? How can it keep me from writing my passwords into plain text files? This is why I think user education is at least as important as a secure stack, and should be considered by the states worldwide as a lesson in the public schools, ASAP. Our lives are going completely online, and most the people don't know what to do and what might happen.

[nickpsecurity]

I already agreed with you on that. It was malware and secure-on-insecure-OS points I was countering.

I'll add that user education has mostly failed. The recent consensus in INFOSEC is we need to design solutions where it's hard to do it insecurely and still easy to use. Signal messaging app is a great example of that. Another is Combex's PowerBox scheme for permissions on files where file dialog transparently grants a single file's access to app when user uses it. OS or runtimr protects its security. But, what user is giving to what application is clear even without technical knowledge.

So, education plus better design like I described is next steps.

[woodman]

> ...because of their use of insecure third party services...

The OS is partially to blame for that. I've got all my external services separately jailed in FreeBSD, with firewalls tuned to each service. Unless they come packing a 0day jailbreak exploit - a compromised service will spread no further, the web server isn't going to be SSHing into the kerberos server. Having your DB dumped sucks, but the really embarrassing compromises (HackingTeam, AshleyMadison, HBGary, etc) involved establishing a beachhead on a vulnerable service and then pushing in further.

You can manually set these thing up in any OS, but the easier an OS makes it to be secure - the more likely it is that the machine will be secure.

[ktRolster]

The only thing lacking for me on OpenBSD is it doesn't run Wine. Otherwise I would jump to it in a heartbeat...

[mulander]

Wine doesn't and probably never will work on OpenBSD.

- http://lwn.net/Articles/360312/

- https://www.winehq.org/docs/winedev-guide/x2803

[cisstrd]

I don't know it from the top of my head, but FreeBSD runs Wine iirc and afaik FreeBSD 11 (I know, not OpenBSD) will introduce bhyve, a hugely hyped hypervisor/virtual machine manager supporting among other things Windows Operating Systems, also there should be some improvements to the Linux Emulation Layer.

Also there is this https://github.com/tony/steam-freebsd-client but not sure how good it works.

This might or might not be of interest to you, since chances are it might I thought I'd share. I don't think FreeBSD is much more secure (if any) than some of the better GNU/Linux distributions though. So it's easier to just run Gentoo or something similar.

[ktRolster]

Here it is (not available): http://openports.se/emulators/wine

I don't think FreeBSD is much more secure (if any) than some of the better GNU/Linux distributions though

I do, and I've look through the source code of both.

Edit: too early in the morning. I misread FreeBSD as OpenBSD in that sentence

[cisstrd]

https://www.freebsd.org/doc/handbook/linuxemu.html

This way you can run Wine... PC-BSD users have done so for a long time now as far as I know.

[nickpsecurity]

It's really the focus. FreeBSD operates a little closer to the cathedral model where they're pickier, more deliberate, and more consistent. Linux takes in about anything to maximize features and development pace. Probably the reason FreeBSD has higher quality in code. Just different priorities.

Of course, I watch these communities from a distance. I'm not in the trenches over there. So, I could be way off. :)

[SkyMarshal]

That seems to have always been the case, all the way back to the Torvalds vs Tannenbaum debates.

[floatboth]

bhyve already shipped in 10-RELEASE!

[JoachimSchipper]

FWIW, if your Windows applications are not demanding you may be able to get by with qemu.

[nickysielicki]

QEMU works fine, and the hypervisor is getting there.