Keep in mind that this article is specifically discussing defaults, though, not necessarily the overall potential for security hardening. There are certainly some security-related features FreeBSD is missing when compared to other BSDs (OpenBSD) or Linux distributions, but some of what is called out can absolutely be accomplished by system administrators after installation, or as part of image deployment… but it would be better if the defaults evolved to be more secure without extra configuration.

As general purpose operating systems go, there was another interesting article from earlier this year comparing popular Linux distros which found that Ubuntu (18.04) had the best overall posture with regard to use of hardening and mitigation mechanisms out-of-the-box vs. versions of CentOS/RHEL, Debian, and OpenSUSE at the time. Some of this was due to the newer Linux kernel version being used, but also thanks to hardening of binaries, etc.

> Our experiments indicate that Ubuntu 18.04 shows the largest adoption of OS and application-level mitigations, followed by Debian 9.

https://capsule8.com/blog/millions-of-binaries-later-a-look-...

I’m surprised that Fedora wasn’t studied, given their stance on security and all of the features they include by default: https://fedoraproject.org/wiki/Security_Features

I think it’s probably because for server usage, RHEL/CentOS is used significantly more than Fedora (with its shorter supported lifecycle), and Fedora is essentially the upstream for shakeout testing prior to inclusion in RHEL/CentOS, so hardening and security technologies – e.g. SELinux, fstack-protector, etc. – are very close. RHEL/CentOS 7 was based largely on Fedora 19, and newly-released RHEL 8 is based largely on Fedora 28.

Probably only true for OpenBSD. See https://youtu.be/AvSPqo3_3vM for anecdotes about the security policy of each.

Freebsd has never marketed itself as being secure though. It’s supposed to be the most compatible/user friendly of the bsd’s

I fear this piece is being taken as a “hit piece” when it should be taken as an aid in hardening a FreeBSD box.

Well, the delays in adding ASLR and W^X (have the added W^X yet?) aren't something you can work around by hardening.

Despite my sibling post to yours I think it's a good point. This https://forums.freebsd.org/threads/no-aslr-upstreaming.54771... has some content that may be of historical interest as to the why the ASLR delays (I can't speak to W^X). Going forward ASLR may take no more than another boot time knob twiddle https://wiki.freebsd.org/ASLR to add to OP .

It's both. There's a lot of prose questioning the intent and competency of FreeBSD developers. The addendum for instance smarmily suggests that the PTI patch had no review at all when it certainly did and the referenced post even contains a link to that review.

That's exactly what's happening

I take issue with you treating yourself more harshly than the OP's author treats his machine. Just to hit one point as the OP has all kinds of non-disputable other points, I'd wager no typical linux distribution ships with swap encryption enabled, do you know if any of them do?

Most Linux images deployed on cloud providers I’ve seen don’t even have swap by default… it’s up to the user to add swap if necessary. I haven’t seen any installers default to encrypted swap, however.

I know Google Cloud by default encrypts the entire disk, which will include swap. Not sure about other providers though.

Once you’re setting up a BSD, you’ve signed up for lots of post install configuration. The installers just aren’t meant to be as “batteries included” as a Linux installer.

I’d go so far as to say that you shouldn’t touch a FreeBSD or OpenBSD install unless you’ve already done and maintained a gentoo, arch, or LFS install.

OpenBSD is much easier to install and get working than any of the Linux distros you mentioned. Post install configuration might take all of an hour, and it's secure by default, unlike those mentioned.

And by "post install configuration," I mean adding XFCE or other DE or WM, along with whatever apps you like. No tweaking needed to close security holes.

There’s a bit of silliness with resource limits (that I think should be configured to match the user’s hardware or at least mentioned in the installer), but overall I agree completely. The base system includes a couple of window managers, including CWM which is quite nice. On a laptop you have to enable APM, but after that you’re just about done.

I’d say it’s about equivalent to a simple Arch install on easy hardware, although OpenBSD comes with quite a bit more security stuff pre-configured.

I haven't touched any of those Linuxes yet run FreeBSD as my primary laptop OS, a home server and a few remote servers just fine. It takes more time to get FreeBSD running properly than, say, Debian, but nothing to put new users off. There are HOWTOs on how to get it quickly operational on a solid level, for example, for desktop use [1].

While you're doing the initial configuration, you get to learn a good deal about what the OS is made of. I found investing a little time to get familiarized with the system components results in more confidence as a user, rather than simply letting the OS do its magic and then wondering how it works later on. Like moving into a new house... You want to know where the fuses are and how to shut off the gas valve.

[1] https://cooltrainer.org/a-freebsd-desktop-howto/

I suppose I could agree if only so the new FreeBSD user has a reference to compare by going through what the guys on the other side of the tracks have to do to rebuild everything from source, kernel and ports. For FreeBSD users its a pair of svn updates, a make world, maybe a reboot, and a portmaster -fa. From what I remember with slackware and from lightly reading advocacy threads like this one it's unusual for linux folks to build their own anything with the exception of the kernel.