[New to Gemini? Have a look at my Gemini FAQ.]
This article was bi-posted to Gemini and the Web; Gemini version is here:
After I completed the previous article, Franco Fichtner announced that OPNsense and HardenedBSD will be parting ways.
I’m happy to see that they are parting ways in good terms. So there at least were no ugly things going on behind the curtain. The explanations given in the announcement are interesting and I’d say that they make sense. This is a pretty massive change, though. And since (thanks to the friendly Web UI) OPNsense is used by a lot of people who do not have a FreeBSD background, I’d like to explain in a bit more detail what the actual situation is like.
In the first series of posts, the second one was an excursion on using the serial console. This time we’re going to take a look at the broad topic of security.
What is “security”?
FreeBSD has had incredibly talented security officers like Colin Percival, founder of the Tarsnap backup company. His company’s motto is Online backups for the truly paranoid – and it lives up to that. Thanks to him and many great people in the security team, FreeBSD has built up a fairly good reputation regarding security with a lot of people.
There are other voices, too. For example one former FreeBSD user who switched to OpenBSD is industriously working on making FreeBSD look bad. Here’s the homepage where he keeps track of all the things he thinks FreeBSD does wrong.
So which claim is true then? Is FreeBSD doing pretty well or is it downright horrible?
Both of them. And neither. Oh well… It’s a bit too complicated to give a plain and simple answer. So let’s think about what “security” actually means for a moment before returning to judge FreeBSD’s performance in that area.
There are multiple aspects to security. To take the whole situation into consideration means to admit that we’re in one giant mess right now!
Living in a nightmare
We absolutely depend on today’s technology. Think about replacing “the Internet” for example. Even if you have this exceptionally great idea and can provide a concept that is totally sound – how do you think we could get there? Millions of enterprises require the Internet as we know it to continue working as it does. The chances of succeeding with establishing something better that would run in parallel? Basically nonexistent. Nobody could pay for such a huge project! And even if it were to magically appear and be available tomorrow (somehow production-ready by day one), how do you think getting a critical mass of businesses to adapt it?
Incrementally improving what we have is hard enough. If you disagree just think about disabling anything but TLS 1.3 on your employer’s webservers. You, dear reader, probably are ready for such a change, I wouldn’t doubt that. But are all your customers? And that’s only one example of… many.
While being condemned to never being able to “re-invent the wheel” in large scale is unfortunate, it’s not catastrophic. What is catastrophic however is that the very foundations of the technology we’re using today were very much over-credulous from today’s point of view. It’s perfectly reasonable not designing network protocols for security when you don’t think of potential offenders because your network is either limited to one institution or basically to a couple of universities! We’ve outgrown those innocent times for a long time now however. The Internet is a war zone.
If you feel brave, join us and participate in our Gemini experiment (see top of this article). Get a Gemini client, read this article over that protocol. Ideally get your own gemlog started and share original content with the world. While we’re not even dreaming of replacing the Internet with something better – even the very act of challenging the Web alone by providing an alternative for like-minded people who loathe superfluous complexity, is an Herculean effort in and of itself.
But back on topic. Retrofitting security into existing technology that’s already in production use is incredibly hard. Especially if you are supposed to NOT break the former! And if it wasn’t hard enough, this scenario also comes with the curse of optional security which is another pretty sad story by itself… Your DNS server probably supports DNSSEC by now. But does it use DANE (mine doesn’t, yet…)? And how many of the more popular nameservers on the Internet do? I mean, it’s been almost a decade since it was introduced. We need regular “DNS flag days” to force people adapting somewhat acceptable DNS standards. How much can we expect optional security features to come to wide-spread use?
And if all of that wasn’t bad enough, in 2018 we learned that the one most important CPU architecture (x86) has a flawed design that dates two decades back… If you want to refresh your knowledge of what Meltdown and Spectre are, here’s an excellent read (explained so that each and every layman can understand it) by the aforementioned Colin Percival: Some thoughts on spectre and meltdown.
Another point is that while almost everybody tends to agree that security is “important”, few want to actually spend money or effort to improve it. Reading last year’s FOSS Contributor Survey of the Linux Foundation gives you an idea of how bad the state of affairs really is.
It’s 2.3 percent (on average!) of a developer’s time that is spent on work to fix security-related issues in their projects. If you assume a paid developer working 9-to-5, that’s about 11 minutes per workday, adding up to not even an hour a week… It’s a clear trend to rather work on exciting new features than fixing bugs in existing code. Working on security-related bugs is even less popular. How many people with such a mindset would you expect to proactively audit their code for flaws regarding security?
Security as “surviving in a deadly environment”
We set sail and started exploring silent waters around the coast with a pretty much experimental boat. It has been a very exciting ride – because at some point we realized that we were no longer near the coast but somewhere in the middle of the ocean. So what was really a nice toy before has turned into a necessity for us to survive. Quite a while ago we noticed that we were in stormy water and that we had to constantly fix our humble boat when the force of another tide tried to smash it! We’re constantly fixing new leaks and fighting off dangers that nobody really anticipated. And to make it even worse, while a lot of people were interested in tuning our boat for performance, they didn’t want to see that the water around us started boiling. Today we’re surrounded by lava. There is no lifeboat. If you shipwreck, you’re dead.
That picture should have either reminded you of what you already knew – or have been eye-opening regarding our situation. There is no need to panic (that wouldn’t be helpful), but don’t fall into the trap of simply dismissing the shadowy dangers. They are very much real! So whatever helps your employer survive in this situation could be thought of as a security feature.
There is no single panacea but combining a lot of security features can drastically lower the threats. Here are some important bits:
- Respond to discovered vulnerabilities in a timely manner
- Offer the latest versions of software or backport fixes
- Provide means that harden the system
- Develop mitigations for when (not if!) your first line of defense is breached
- Make it as easy as possible for the user to secure the system
Where FreeBSD does mostly well
When it comes to patching base system vulnerabilities, FreeBSD is generally doing well (there’s no point in denying that things do not always work like they should so that blakkheim can point a finger at it). If you’ve never read a security advisory as published by the FreeBSD project, I suggest you do so at least once to get an idea. Like the latest one.
As you can see, the security team does not only silently fix bugs but even goes an extra mile, doing a write-up for the interested reader. For years I’ve been very happy with those; I’m not a developer with sharp C skills and deep knowledge of exactly how programs work, but I can always understand what’s going on there. I’m not spiteful enough to ask you to compare them with OpenBSD’s errata which are… very bare-bones.
If you take a closer look at the example provided here, you can see that among the versions that received a fix is 13.0-RC5-p1. That’s right: This means that they even cared enough to fix it for a Release Candidate that has a lifecycle of two weeks! And not only that, they even provided binary updates for that even though people on RC5 could just be expected to update to 13.0-RELEASE only a couple of days later. I’d say that this is nothing short of very commendable acting.
Regarding packages that are not vulnerable, the situation with FreeBSD is a mixed bag. There are quite a few unmaintained ports stuck at older, insecure versions. Common software is usually pretty recent. To give you an idea (and so that you don’t simply have to take my word for it), let’s compare FreeBSD and Ubuntu 21.04. FreeBSD currently has a port count of slightly above 31,000 whereas Ubuntu offers just short of 33,000 packages. A little over 6,000 are outdated on FreeBSD, for Ubuntu it’s over 8,500. For ports beginning with the letter “A”, FreeBSD has 9 ports with versions that contain a known vulnerability (with a CVE) that could be fixed by updating to a newer version whereas Ubuntu has only 3. Same thing for ports that begin with “Z”: 1 vulnerable port that could be fixed by updating to a newer version on FreeBSD, 2 such packages on Ubuntu.
Just so nobody claims I’d selectively present data to support either story with it, here’s a table for package CVEs of all starting letters:
|Starting letter||FreeBSD #||Ubuntu 21.04 #|
I think it’s safe to say: FreeBSD does pretty good in this field, too! Especially if you take into consideration that most of FreeBSD’s ports are done entirely by volunteers and that while software usually “just works” on Linux there’s often some more work required to make it work on other operating systems! (Of course I’m aware that I’m just scratching the surface here and a deeper analysis would be nice – but that would definitely take its own article.)
Let’s talk about means of hardening the system. There’s a lot you can do to harden a system that was installed using the default options. For a while now (I think starting with 11.0) FreeBSD offers a hardening dialog in the installer, allowing for really simple improvement of the defaults. This is one thing that blakkheim prefers to ignore: Yes, /tmp is not cleared by default, but FreeBSD can do that if you want it to and it’s not hard to make it do that.
Yes, hardening a FreeBSD system is not something you can expect the junior admin to master in a couple of hours. But that doesn’t mean that it’s impossible to do. With securelevels and file flags, FreeBSD gives you a powerful tool for increased security. Capsicum and casper are two more things you can take a look at and start making use of. Taking advantage of jailing applications is another great way to make your infrastructure more secure by confining possible intruders and further limiting the damage they can do. FreeBSD expects you to do all that and more, depending on what your security requirements are.
Definitely have a look at security(7). To quote from it:
A little paranoia never hurts. As a rule, a sysadmin can add any number of security features as long as they do not affect convenience, and can add security features that do affect convenience with some added thought. Even more importantly, a security administrator should mix it up a bit — if you use recommendations such as those given by this manual page verbatim, you give away your methodologies to the prospective attacker who also has access to this manual page.
Does that really sound like it’s written by people who do not care for security at all as our friend blakkheim wants you to believe?
So far for the good part. The ugly side of FreeBSD will be covered next time as this article is already way too long. Thanks for reading!
The next post will briefly discuss FreeBSD’s security weaknesses and how HardenedBSD fits into the picture. I’ll also address the “rebase it on OpenBSD!” suggestion some people have made.