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...
"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 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.
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.
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_.
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.
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.
"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?
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.
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.
> ...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.
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.
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.
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. :)
We also owe the OpenBSD team OpenSSH, which greatly benefits from their attention to detail and commitment to small improvements towards better security.
Of course software is never perfect, but it's nice to know the (small) subset of OpenBSD developers working on OpenSSH are still working on keeping the proverbial doors locked.
Yes, the OpenBSD team's willingness to roll up their sleeves for software that I consider core to a functional Internet is pretty remarkable. Even though the last OpenSSL vulnerability also affected LibreSSL, in the past others haven't.
EDIT: Morning brain made context shift unclear. They do OpenSSH and now LibreSSL. Also pf and more too.
I just want to shake the hand of the person who made the OpenBSD installer the way it is.
In case you haven't used it, it's dead-simple, command-line based, and it may take a few times to get it right if you don't know what you're doing. It's nearly featureless.
But after you figure it out, you can automate installs, and roll your own distro by changing the contents of tar files, or add your own software and configuration the same way.
It's quite possibly the most satisfyingly transparent OS install method I've ever used.
Indeed, the only distros in the Linux world with installers that even come close are Alpine Linux (which is obviously heavily influenced by the OpenBSD installer) and Slackware Linux, coincidentally two of the better Linux distros for those who prefer a more BSD-style approach to managing the OS proper.
Alpine needs a little work in the desktop OS department, and is painfully lacking in a few essential packages for daily computing, but it's come a long way in a short time. Meanwhile, Slackware is due to drop 14.2 on us any day now, and has seen vast improvements over the past few years. Both are worth a look if OpenBSD for some reason doesn't work on one's system.
But having said that, OpenBSD is a cut above any other open source OS when it comes to stability, clean code, and well written, complete, thorough documentation.
I wanted multiple times to study the OpenBSD source code and I've downloaded it but I never managed to navigate through it, to find the "head and the tail" or to find a reasonable "map" of the source code. I would like for example to follow the execution path in the source code, from the boot up to the login prompt. Does any documentation like this exist or could anyone give me some hints ? Thanks
1. Boot up - this is very machine-dependent ("MD") so you'll find it in each architecture's source code. Look for files named "locore.s" or "locore.S" in places like src/sys/i386/i386.
2. Kernel - the machine-independent ("MI") part, or where the fun begins... this is in src/sys/kern/init_main.c, look for the function main(). You'll see the different subsystems initialized, from the lowest level (auto configuration of hardware devices and console initialization) through fundamental subsystems (virtual memory, disk, network, processes, etc.), all the way to the scheduler. The scheduler will only have one process to work with (PID 1) which is init (src/sbin/init), so that's what gets executed.
3. Userland - /sbin/init is the first process that runs, and it takes care of running everything else, like daemons and eventually your login prompt. Your points of interest in init.c are runetcrc(), read_ttys(), and multi_user().
While not a walk through the code base, there are these wonderful volumes: http://www.aosabook.org/en/index.html that have creators/maintainers/contributors walk through at a higher level how these amazing programs work.
Not a map per se, but I find bxr.su is a great resource to browse *BSD source code. OpenBSD is quite close to its' 4.4BSD roots, so "The Design and Implementation of the 4.4 BSD Operating System" book should still be pretty accurate.
Probably worth noting as well how many software products OpenBSD has contributed back to the overall free software world; things like OpenSSH, (edit: NOT OpenSSL), a more secure ntpd and inetd.
Even if you don't run OpenBSD, you benefit from it.
> how many software products OpenBSD has contributed back to the overall free software world; things like OpenSSH, OpenSSL, a more secure ntpd and inetd
One of them is not like the others -- OpenSSL is not an OpenBSD project and the code quality is markedly different :-)
Yall don't be too nice to them. The code quality is shit. My favorite quip of all came from Ted Unagnst noticing they did endian-checks in one code that ran very often during use of protocol. He said something along the lines that they hadn't applied any sense to (important issue) but they had you covered if your CPU's endianness changed in mid-operation. No words. :)
Great opinion piece. I think this is mostly the opinion of anyone that really discovers OpenBSD and gets caught up in it. Security does matter, and the developers accept nothing less than what they want.
My main problem with OpenBSD development is that all development is decided solely by the developers and there doesn't seem to be much care for what others want.. which is fine, they're doing all the work for peanuts.
Sometimes you just have to do things that aren't well suited for OpenBSD (imagine updating and ensuring hundreds of OpenBSD machines are up-to-date, and running high performant threaded applications). Many things work, but that is all they do. Sure it may be much more secure than other unix or linux offerings, it may be all there is. Much of the ports are just "get this to compile and work". That isn't always good enough. Truly evaluate if it fits your needs. If there is something you want on the platform, it may be up to you to fix it.
--
Unrelated, I find it interesting that NetBSD isn't mentioned once in this entire thread.
I've seen this type of comments many times, in many different context, about many different open source software projects, and I never understood them.
> all (OpenBSD) development is decided solely by the developers and there doesn't seem to be much care for what others want
This implies this is not the case for every other project.
To pick on your SMP performance example, Linux doesn't have better SMP because "developer saw that people want SMP, and decided to implement it". Linux has better SMP because some people came and implemented it. Not at other's people request, that is never relevant.
Different open source projects attract different (developer) audiences, and different project have different audience sizes, but don't make the fallacy that some projects chose what to work on (architecturally speaking) because user demanded it. That is never the case. Everything big happens because developers want it.
It isn't a "fight" or a "Linux vs OpenBSD" thing. It is just how they approach development. One could argue if it is "good" or "bad", but what matters is knowing it exists.
Many projects have different approaches to development. Sure, many people work on bugs most of the time, but there are big decisions about where the limited resources are going to be spent on new features. Those are the ones that truly matter.
There are examples of amazing things people have just done on a whim, but that isn't truly a standard and much of those things are generally huge.
I'm lumping Linux in that group because my impression is that Linus is ambivalent about security--it seems to be just another feature to him (see http://www.washingtonpost.com/sf/business/2015/11/05/net-of-...). Additionally, with most of the popular distros, once I install the OS, I have to spend a bunch of time locking things down before I do anything else, whereas OpenBSD has pretty good defaults that I can build up from. Also, when Ubuntu, one of the most popular Linux distros, started capturing searches by default, that got me questioning their commitment to privacy.
That's not to say there aren't distros and contributors to Linux that care deeply about security--clearly there are. I just don't find the overall ecosystem nor the most popular distros nearly as focused on or as trustworthy on security and privacy. And as the stakes get higher with more of our lives going digital and more companies, states, and criminals trying to take advantage of that trend, I worry.
As for OpenBSD vs FreeBSD, I've had an easier time getting OpenBSD working on my hardware and OpenBSD seems to me more concerned with, focused on, and practically innovative on security--that is to say, they don't just introduce new security features that can be configured and used by someone smarter than me, the OpenBSD folks work hard to introduce new security tech that's on by default with no special knowledge required by the end user, i.e. pledge, W^X.
Then modify the claim to say "some Linux kernels/distros" instead of Linux as a whole. Meanwhile, thanks to CompSci, there's Linux's (eg Criswell's SVA-OS) and FreeBSD's (eg CheriBSD on CHERI) that run with way more security than OpenBSD. They push the state of the art. So, it's a mixed bag.
OpenBSD is actually no different. The developers care a lot about security and quality. Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp. It's just the kernel and select userland that gets their attention to quality due to limited staff (and their preferences).
> Yet, the mere fact that I see OpenBSD desktops in Google images running shoddy applications shows many OpenBSD users make similar tradeoffs to what you described of Linux camp.
Are these "shoddy applications" not more secure on OpenBSD due to the various mitigations applied to userland software?
We don't know. OpenBSD has so little market share that virtually nobody is testing those mitigations. However, many are similar to mitigations developed on other platforms and beaten. So, they'd probably be beaten with effort, too.
Don't you love reasoning by precedent? Makes these judgment calls so much easier. :)
People are testing the mitigations. For example Qualsys' audit of OpenSMTPD[0] noted that a buffer overflow they found was not exploitable on OpenBSD as even a single byte overflow would smash the stack canary.
That's not trying to break the mitigations: it's simply testing if they stop an exploit which isn't designed to bypass the mitigations. Really easy to pull off. :) Below are examples of a clever scheme for stopping control flow attacks and a successful attempt to breaking it. When I say testing the mitigations, I mean work like what's in the second paper.
I'm not seeing your point. A vulnerability was found in OpenSMTPD. That vulnerability could not be exploited on OpenBSD because there was no way to overflow the buffer without smashing the stack canary. If you had the same version of OpenSMTPD running on a generic Linux kernel or on Mac OS X, it was vulnerable. On OpenBSD it was not. Ergo, OpenSMTPD running on OpenBSD is more secure than OpenSMTPD running on other platforms that do not provide the same mitigations.
At least, that's the way I see it.
Now, are you saying that because it's possible to bypass the mitigations in some other cases, preventing that vulnerability (and others) doesn't matter?
Or, are you saying that it would be possible to craft an exploit that bypassed the stack protection for that particular vulnerability? In which case I would love to see your PoC.
What I'm saying is simple: there's the security of the code and the mitigation itself to consider. I know of no talented people interested in devrloping bypasses for OpenBSD mitigations since nobody uses OpenBSD. So, they break even more clever stuff in Chrome, Windows, etc. Given your example, lets change the mitigation to make it more obvious, though.
OpenSMTPD (email for short) is the target. Default are Windows, Linux, and OpenBSD on x86. OpenBSD devises a mitigation: use SPARC processor since x86 malware cant work. As you say, the malware works on everything but the SPARC box. You and others claim it means the mitigation is secure and so is what uses it.
Now, some guy named Nick claims it's no more secure than a BSD/Linux 0-day on x86: they just didn't target exploit for that environment. Sure, they have to learn SPARC ISA and how OBSD uses it. Sure there's work involved. Similar mitigations were beaten in the past by first person willing to invest effort, though. So, Nick posits reason SPARC is safe from x86 malware coders is that they don't care enough to deal with SPARC boxes. Maybe no market share.
Basically. Now, it's fine to throw in obscurity or unusual mechanisms on top of good security practices. I used that to stop high-strength attackers before. Yet, we must be careful to note the difference between these mitigation results:
A. We stopped those vulnerabilities from working because nobody can bypass this mitigation.
B. We stopped those vulnerabilities from working because very little talent is working on beating our mitigation.
World of difference there as Chrome and SFI/CFI teams I linked up above found out when smart hackers and braniacs from CompSci began convergjng on their work. And shredding it.
Code-Pointer Integrity was last one standing after first round of peer review. I'll use it for medium-assurance if it survives 2-3 more. Check it out.
>If you had the same version of OpenSMTPD running on a generic Linux kernel or on Mac OS X, it was vulnerable
You're completely wrong, stack canaries have nothing to do with kernels, they're a compiler option, gcc has them enabled by default, clang has them enabled by default. So no, running OpenSMTPD on Linux or OS X would not make that vulnerability exploitable.
Dumb question: Do you mean the field of computer science in general, or some specific tech or organization that uses that name? The former doesn't exactly make sense, but I've not heard of the latter and would be interested ...
It's not a stupid question since I never define it. :) I had an extended discussion/debate with Kragen a while back on engineering software vs programming it. Many in academia and industry came up with methods to do software like a form of engineering with great results in practice. Sometimes even proving its properties. Whereas, programming was anything from throwing crap together to carefully constructing it in a way that uses a subset of engineering concept. I eventually realized we were tripping over definition of "software engineering" since people on his side of fence had that forever tied in their mind to groups pushing processes and Big Methodologies over good code. He kept referring to CompSci so I decided to use it to represent top work out of academia on engineering software to avoid red-flag phrase of "software engineering."
In any case, I can give you some links to illustrate engineering software vs merely programming it. The first gives the concept with good analogies showing why we need it and what the difference is. Others are examples of methods for doing it.
Hope these help illustrate what I mean by engineering software. Although, my use of the CompSci term includes anything else scientific or cutting-edge that's coming out of academia. I'll toss in one more showing secure browsing done right (maybe). :)
> Nobody really objected to the patch series as a whole, but Linus hated the name of the configuration option; he asked that it be called CONFIG_LEGACY_VSYSCALLS instead. Or, even better, the change could just be done unconditionally. That led to a fairly predictable response from the PaX developer on how the kernel community likes to hide security problems, to which Linus said:
>> Calling the old vdso "UNSAFE" as a config option is just plain stupid. It's a politicized name, with no good reason except for your political agenda. And when I call it out as such, you just spout the same tired old security nonsense.
I think this line was meant mainly to refer to his closed source iPhone, OS X, and Windows use. Perhaps he means his Linux usage is one of the more mainstream distributions that readily facilitates installation of binary kernel blobs (e.g. wifi, video), or 3rd party closed source software.
He may also be calling Linux insecure due to it being less uncompromisingly about security. Same could be said about FreeBSD--they aren't necessarily insecure, but they are not as explicitly focussed on that.
OpenBSD invests a great deal here. They have their own fork of Xorg (or was that XFree86?) that runs not as root. As far as I know that's unique amongst libre *nixen.
EDIT: this is what I get for starting a response, getting coffee and resuming my reply. We don't have to speculate what the author of is post intended, and his response is better than mine ;-)
> OpenBSD invests a great deal here. They have their own fork of Xorg (or was that XFree86?) that runs not as root. As far as I know that's unique amongst libre *nixen.
It's a standard feature of Xorg nowadays, but it's only a feature of vanilla Xorg for a few years.
AMD only added KMS to their proprietary driver last year, and Nvidia this year (and IIRC only in a beta driver so far); and systemd makes the permission handling a lot easier. So Ubuntu will transition to it eventually, but didn't have all puzzle pieces until too recently for even 16.04 LTS.
IMHO, I found it unconvincing. It soured me on the rest of the episode and its not really my watch as soon as its out podcast anymore. I guess since every segment is basically a FreeBSD segment no matter what OS they are talking about, it had to go that way.
why not freebsd? the freebsd project seem to focus exclusively on post-attack with jails and trustedbsd mac. fbsd has not implemented any of the modern exploit mitigation techniques. i mean, even os x has had full aslr since 2012 lol.
some years ago fbsd was forked to hardenedbsd which has aslr, mprotect restrictions, non-exec pages on cpus w/o NX, randomized lib loading order, etc. i guess the freebsd project is too busy fighting meritocracy cus none of it has been merged as far as i can tell.
as for linux, plenty has been written on linus' stance on what he considers to be a "security circus"; and the mantra on lkml is still that "a bug is a bug". just watch oss-sec and see distro people wading through kernel commit logs (hyperbole) cus sec-related bugs usually aren't reported downstream
> FreeBSD lacks basic low-level exploit mitigation, such as Address Space Layout Randomization (ASLR)
the whitepaper you linked was published in 2014 by Shawn Webb, one of the people behind the hardenedbsd fork. that same year a submission for review was opened on phabricator[1] re. merging their aslr work in mainline fbsd.
it was closed on 2015-10-19:
> Closing this revision. FreeBSD is free to pull from HardenedBSD.
another aslr review request was then created on 2016-03-10 by Konstantin Belousov[2]:
> This revision needs review, but there are no reviewers specified.
that same day he sent a call for testing to freebsd-arch[3].
there is also a bugzilla ticket[4] for the people waiting for freebsd to catch up with 2001.
FreeBSD lacks (or disables) most mitigations OpenBSD (and usually Windows, or some Linux distros) have, like ASLR, stack protector, W^X, PIE applications by default, libc.so symbol randomization, pledge()'d ports, etc.
I love FreeBSD, and use it a lot, and I wish these were all implemented, but until then, it pains me that FreeBSD has less mitigations enabled than Windows and good Linux distros.
Since OpenBSD can be backdoored[1] with the same ease that the Linux kernel could be backdoored, I have no idea why all the fuss. Debian is pretty thorough in NOT including proprietary software if that's what we're talking about.
As far as I'm concerned, it's good to have options and the OpenBSD developers have created software that I use daily (OpenSMTPd, SSH, PF, etc.) and for that, I'm thankful!
ps. I know that developing IPSEC backdoors is not easy by any means. But the subsequent Theo De Raadt answer, was that he can't tell if there are backdoors or not. That was my point.
No, no with the same ease.
Every OpenBSD commit is throughly reviewed, and there is only a bunch of commiters. Compared with linux, with thousands of commiters and tons of code added every day, OBSD is way more difficult to backdoor.
Not having a formal kernel module system does not actually mean the kernel is secure. Exploits to create module loading systems out of kernel vulnerabilities are approximately as old as stack overflow exploits.
NX enforced kernel W^X, SMEP/SMAP, always-on stack protector and a limited attack surface (..say, from pledge(2)), only serve to make such theoretical attacks impractical against OpenBSD.
I'm glad you're saying it, too, as I get tired of this myth. I wrote a scheme on Schneier's blog for disproving it a while back. Basically, you counter the mitigations which look awfully similar to the one's that got countered in Linux and Windows. Once you have that, wait until a bug is mentioned on mailing list that can lead to memory attack. Weaponize it. Profit.
Leads me to what I claim is dirty secret behind "only 2 holes in..." claim they have: OpenBSD just fixes bugs they find without serious attempts to determine if they'd be exploitable vulnerabilities. They just do accounting differently than the rest. So, by their numbers, they only had 2 vulnerabilities because they didn't assess whether other bugs were vulnerabilities in the first place.
They have good code quality but they're full of shit about how vulnerable it is or isn't.
What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release.
For a normal user that's fine, but if you have a bunch of servers you'll need a sophisticated build/deploy infrastructure to stay updated.
That means no Internet-facing service has ever had a bug of the sort that often becomes code-injection. Or they didn't test for exploitability in the case of mitigations being bypassed. Neither one makes the claim stand up as it has hidden implication of "only two remote holes for amateurs and people ignoring mitigations."
"What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release."
Yeah, that sounds like it could be annoying. They should have both options available given they already have to trust OpenBSD team to not backdoor their stuff.
"Only two remote holes in the base install". That's because the base install contains very little in terms of remotely accessible services (only OpenSSH I believe?).
Even as an OpenBSD fan, I'm not sure why tptacek was downvoted here. W^X etc. make it harder to write an exploit, but sufficiently-bad bugs can still yield arbitrary code execution. (Or confused-deputy problems allowing escalation to root, etc.; there's more than one way to pwn a box.)
And - architecturally - OpenBSD's kernel isn't that different from Linux, both being UNIX-style kernels; to the extent that OpenBSD's kernel has better security than Linux, it's mostly because OpenBSD tends to have fewer (and, sometimes, better-considered) features.
(There's an interesting argument to be had about Linux+grsecurity vs. OpenBSD - focusing on having some cutting-edge parts vs. solid engineering throughout - but that's not the argument we're having.)
Do you need a "truly wonderful proof" for "the mainstream OS OpenBSD has not managed to render kernel vulnerabilities unexploitable, or to rid itself of those vulnerabilities entirely"? Because: that's an extraordinary claim for an OpenBSD supporter to make.
I did write a remote kernel exploit for OpenBSD, it was not an easy task, and this was in a time when there were basically no exploit countermeasures in kernel (2007) (https://www.coresecurity.com/content/open-bsd-advisorie)
There are a bunch of local kernel exploits, all very practical and reliable. Kernel protections are something OpenBSD lacked until very recently.
That timeline isn't pretty. The OpenBSD guys really needed to be dragged, kicking and screaming, to calling it a "security fix" rather than something milder like a "reliability fix".
> OpenBSD is a great example of the value of competition, and the necessity to maintain market rules that encourage it.
The market doesn't work here. The OpenBSD people aren't responding to market incentives; they aren't earning much (AFAICT). They appear to be responding to internal incentives. The market's incentive for talented developers is to work on something else and get paid more.
That is, they appear to be doing this despite the marketplace, not because of it.
I suppose it depends on if we're talking about server-focused OSes or desktops - for the desktop, there's Qubes[1] and I think it would be fair to say ChromeOS[2] should be mentioned...
For any Linux distro, applying the grsecurity patchset will make your box more secure.
RHEL (and thus, CentOS) does a pretty good job of configuring and enabling SELinux for packaged software.
There is a Hardened Gentoo. All the fun of normal Gentoo, but with fewer companions to find the compiler bugs. ;-) Still, they've built quite a stack of security patches, including grsecurity.
There is (used to be?) Hardened Linux From Scratch. Educational, but not practical.
OpenWall Linux is dead-ish, but - as you'd expect from a Solar Designer product - introduced several interesting patches (some backported from OpenBSD). You may be interested in http://www.openwall.com/presentations/Owl/.
I recommend - and use - OpenBSD, but there are definitely people interested in security in the Linux world.
Oh darn, you beat me to OpenWall. It's one of the earliest attempts at securing the Linux mess that many forget about. Solar Designer deserves some credit for his effort. Modern stuff, esp hardened RHEL or Gentoo, is far better option due to maintenance if nothing else.
The bad thing is there's hardly a generic "more secure" switch.
> applying the grsecurity patchset will make your box more secure.
It also might not. Correct me if I'm wrong, but while grsecurity does a good job in kernel hardening, it won't protect from attacks like recent imagemagick system() injections, or from something like wordpress exploits, where you don't necessary touch kernel space or even binaries at all -- so it might be possible to have grsec enabled system and still be part of a botnet, or leak user data.
> enabling SELinux for packaged software.
This is a double edged sword also. Good thing is that a lot of software does have SELinux policies for it. Bad thing is that a lot of software runs in unconfined domain and that can give a false sense of security. For instance, if I recall correctly, systemd runs unconfined, while being itself a a) rapidly changing and b) half a million plus LOC software. And to err is human, you know -- SELinux won't "contain the bomb as it goes off" in unconfined domain.
Another example of bad approach with SELinux would be grepping for something in the audit.log and making policy module, which is even recommended in the official docs [1]. I do understand that its a major PITA to find good balance between convenience and security, but this particular example trains users bad practice from the start. Its worse than dismissing UACs -- its as bad as grepping for dropped packets in firewall logs and autocreating permissive firewall rules. Attacker calls her rootkit "yoursoftware.sh", tries needed functionality so that denials appear in audit.log, waits until sysadmin greps for "yoursoftware" and voila -- SELinux is perfectly ok and silent with rootkit. Its simplified, but you get the idea.
> Hardened Linux From Scratch. Educational, but not practical.
If we disable unconfined domain -- and hence be forced to formalize literally every syscall in our access matrix -- then any MAC system also can be called unpractical.
I think every statement of a "Use X its more secure" kind is very dangerous, unless you explicitly specify against what kind of threats its more secure. Otherwise, statement just adds false sense of security, and then human laziness kicks in, and we end up with a mess. Like, if I harden the system kernel, but fail to protect the user data -- or vice versa -- I simply end up without any sensible result, while thinking otherwise. Or I can start with perfectly reasonable defaults (same examples like OpenBSD or SELinux) and with few "convenient" commands open up huge security holes, and again, end up with not what I expect.
I ran across this the other day. Looks interesting. Does anybody know the general difference in approach between HBSD and OBSD? They both seem to be trying to achieve roughly the same thing (a security-focussed BSD).
The biggest reason people don't use BSD of any type is that you can't go into a store and buy a computer with BSD on it. At least not in any store an "average" computer user would know where to look.
As for someone like me, I used to build computers (more than a couple hundred) back in the 80s and 90s with alternate OSs to Mac (classic) and Windows but never tried BSD. I did try BeOS and OS/2 and Corel and close to a dozen different Linux distributions (I have the Penguins to prove it).
At the time I didn't know anyone else that used BeOS or OS/2 other than me. Personally I mean. So that isn't my excuse for not using BSD. Mostly I rarely heard about it. Now I'm old (laughing) at 55 and left BeOS and OS/2 behind years ago and moved to Mac Classic and then Mac OS X which runs on top of BSD. That's the closest I've gotten.
If you want more people to use BSD you really need to promote it more. Not just in nerd magazines but put out flyers around companies (don't ask, just leave them) with an explanation of what OpenBSD is and why they should be using it instead of Mac or Windows.
It needs to be brief and clear and you need to make VERY clear how they find and install OpenBSD and not just, "Go out and buy a computer and install it." That's like telling most people, "Go out and buy a nuclear reactor and install for the OS for it." It's not going to happen unless you are clear and you make it as easy for them as possible. People like easy and they want to feel like someone cares and that they will be taken care of if they have ANY questions.
Personally I feel that one of the biggest bad jokes is that "Microsoft cares". Really? Would you like to buy the Brooklyn bridge? Because it's for sale for $1.
If you get everyone you know to lay out flyers at businesses with what I describe above then you may get a few more people to use OpenBSD. But be prepared to support them in not nerd languages and without any attitude. If you have emotional problems (low self esteem, and I'm not saying that YOU do, well those people shouldn't be helping anyone else with anything) then I would suggest leaving support to other people.
Do the downlable .ISOs boot these days? Back when I had time to check it out nearly a decade ago, it cost real cash money to buy a bootable CD-ROM from their store.
Speaking freely is essential to democracy. The more restricted your conversations, the more careful you are about what you say. And being careful leads to less candor, less criticism, and less innovation. Thought and free speech are the breeding ground for new, sometimes controversial ideas. They are how we prototype, think new ideas through, refine them, and get them ready for wider distribution and discussion.
The actions of many 21st century activists seem to be diametrically opposed to this ethos and designed create a social landscape of civic censorship and extra-legal punishment for "thoughtcrime." I think a society with laws supporting free speech on the books, but largely made of authoritarian and censorial organizations is no more democratic in spirit than the Jim Crow south was inclusive with its "technically" enfranchised non-white population. (It doesn't so much matter what laws are on the books, if society at large thinks something opposed.)
For democracy to work, there needs to be freedom to dissent. I think many young people who grew up with web forums were exposed to so much draconian censorship, they've come to unconsciously feel that censorship is a key means of expressing power and "justice." I just hope that enough of them work out how intellectually bankrupt such a society would be.
> Plenty of hardware in my life has backdoors (I'm looking at you Intel[1])
That same libreboot article[1] says that AMD is not any better. Is there any alternative I'm not aware of? An ARM Chromebook is unfortunately not fast enough for me.
I'm just getting started on setting up an OpenBSD router that I want to be the basis for making sure much of my data is secure. I figure I can start with the edge of my network and work in. And for such an important device as an internet gateway, I want to be able to trust it.
> I'm just getting started on setting up an OpenBSD router that I want to be the basis for making sure much of my data is secure.
A bit of warning... I've seen this go wrong when people who don't know OpenBSD do this. Adding an additional OS means learning and "supporting" it.
* If learn your way around, get it set up well, keep your system updated the way you do for anything else, then you'll be in good shape.
* If you learn just enough to get it working and then set it on the back burner for when you can find the time to learn more, don't update it, etc., then you're better off going with an OS that you know and can keep secure.
I'm not trying to dissuade you, but I'd like you to evaluate if you will devote the time to using a new OS on a border device that it deserves. If you will then I think you'll be quite happy with your choice. :)
Indeed! Spoken by someone that seems to have experience maintaining many machines.
As secure as the machine is, its security slowly degrades the longer it is out-of-sync with updates (especially security ones) and/or admins administering the machines aren't good enough.
System administration isn't a set-it-and-forget-it type of thing.
>Plenty of hardware in my life has backdoors (I'm looking at you Intel). But I'm slowly replacing the bad stuff with the good stuff, as I'm able to find OpenBSD (and open hardware) based solutions for my remaining use cases.
Use a blobless OS like Trisquel, Guix and get libre hardware from the FSF.
Reading Bruce Schneier made me especially aware that security has a strong economic component--its not that you can make your server secure against all threats, but with the right tools you may be able to make it uneconomic for the threats you are most worried about. There's probably not much you can do to defend against an NSA-scale attacker that's targeting you individually. But if you're more concerned about NSA-style dragnets or their corporate equivalents, OpenBSD can help.
it's not just that though, there's the push for systemd which was not welcomed and alienated a lot of sysadmin folk who frequent hackernews.
personally I felt rather shafted by systemd, not because it's bad, but because my arguments were never even met, it was just a brushing off from some of the people who had already accepted it.
So I tried the BSD's and they were significantly better than I imagined they would be, I would put money on this being the case for other people who are upvoting these topics.
I'm 23, I used GNU/Linux since I was 11, and about at the beginning of this year (2016) I switched to FreeBSD. It was the first time I had an easily and consistently configurable, recreatable, understandable, enjoyable PC system that went out of the way once configured. It is so pleasurable that I don't even care I can't suspend and hibernate yet, even though I'd hardly turn of my computer and my workflow used to rely on having my laptop on for ten-twenty days and reboots were seldom and because of me forgetting to plug the thing in, or I updated the system. Also, I updated from 10.2 to .3, and it was the most pleasurable, most silent and non-destructive update I ever did. I just merged from /etc and /usr/local/etc to my config repo, and good to go (I have two scripts to copy back and forth the config files into my repo). I expect a mass migration to BSDs to happen soon. They are decent desktops, and soon they'll do better on laptops.
FWIW I did what you did, Linux -> FreeBSD, but when I moved "further" away from linux-land and went to openbsd I was surprised at how much more polished things are.
My laptop (thinkpad X201s) used to idle very rough under FreeBSD and suspend didn't work, but under openbsd it did.
Also there were some hardware drivers which appeared not to work at first but running 'fw_update' caused openbsd to download the device drivers I needed and they started working perfectly.
I'm still shocked how easy it was, sure I miss all my software that depends on /proc and I miss zfs.. but I can't think of an operating system that would fit my thinkpad better.
Well if only I could run OpenBSD on my X51RL... That is, it runs fine, but my wifi card doesn't work. I actually just asked a question on /r/openbsd about that: https://www.reddit.com/r/openbsd/comments/4ilko3/drivers_con... Hope to get some helpful answers there, the case with ath5k is so complicated, reading mailing list and glimpsing over the related C files (I know little C and no hardware) didn't provide any info.
There's also systemd's constant regressions and awkward interfaces and limited functionality when they replace existing solutions. It should have stopped at unifying init scripts, although upstart had that, SMF had it, so it's great to see nosh being cross-platform and able to import system unit files.
Speaking of SMF, it's interesting that the seemingly little effort to recreate it led to systemd, while nobody attempts to create a read/write implementation of ZFS. I mean, if you can accept the license of ZFS (huge piece of code), we could have just as well forked SMF, but a clean slate with a different license may have been a favorable choice.
Indeed. If systemd were just a parallelized init system with better unit management, far more would be okay with this shift.
But that wasn't enough. They had to hijack bootloading, logging, device management, network, etc. For reasons that nobody seems to be able to actually explicate.
They want to control it all to give the best possible user experience but fail short and introduce bugs I've never had since the first day I've installed Linux in the 90s.
OpenBSD's CVS contains implementations of bootloading[1], logging[2], device management[3], network[4], etc. For the simple reason that you need all that to have a useful operating system.
Best i can tell, is a "developers developers developers" thing. The goal is to present a set of APIs that abstract away the underlying OS.
Sadly though this has been done multiple times over, but then discarded because of CADT.
Pop over to Freedesktop.org and you will find the remains of a number of discarded projects. Most of them discarded just as they are 99% feature complete and the devs face the prospect of doing janitorial maintenance.
Not just sysadmin folk. I'm a long time Linux user (since 1993) who has just switched his main machine to Gentoo in order to avoid systemd and has just installed OpenBSD on an old laptop to try it out.
You don't have to be a sysadmin to think it's a bad idea for pid 1 to have a hard dependency on glibc.
It's a nightmare. And it's incredibly ironic that the solution seems to be that you should migrate to operating systems where the userland and kernel are coupled together.
And that's the crux of the argument against systemd. Is clean service management more important than portability? Of course not! Linux has always been interesting because it's portable, not because it's easy or streamlined or standardized.
"Linux has always been interesting because it's portable, not because it's easy or streamlined or standardized."
Pretty sure Tanenbaum would disagree. That said, I do agree that portability really is important. For that matter, I'd really like a decent FOSS microkernel.
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...