vez.mrsk.me

Can confirm this is a very real problem with a long history. Quoting from a sort of Arch-specific security hardening page[1]:

> A common misconception about the Linux kernel is that it's secure, or that users can go a long time without worrying about security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing important security fixes among the other changes. These releases typically don't make explicit mention of which commits have security implications. As a result, many "stable" or "LTS" distributions don't know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a CVE assigned to it, maybe your distribution will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Red Hat and similar "enterprise" distros have the same problem and have been called out publicly about it on more than one occasion. Moreover, the Linux kernel security team doesn't request CVEs for any vulnerabilities, partly because there are just too many to track. Downstream's culture of trying to cherrypick security fixes in the name of stability does not work. Arch doesn't play the backporting game, instead opting to provide the newest stable kernels shortly after their upstream release.

[1]: https://vez.mrsk.me/linux-hardening.html (lots of…

Hi xianwen,

Both servers are SuperMicro with:

- 6 Cores 3.3/4.5GHz (E-2136)

- 32GB ECC DDR4

- 2 × NICs (em, igb)

- 2 × 480GB SSD

- 20TB on 1Gbps with DDoS FENS

- IPMI over VPN

I rent them to Hivelocity.

===

FreeBSD vs OpenBSD

Ilja van Sprundel answers your question by comparing the number of kernel vulnerabilities since 1999 of the BSDs and Linux. [1]

I don't think FreeBSD, even well hardened [2], is as secure as OpenBSD. After all, OpenBSD's main focus is security. I use OpenBSD for orchestration and monitoring, and I have an experimental setup of OpenBSD with VMM but they crash sporadically, so I'll wait a bit.

At any rate, my goal is to have two heteregenous paths (maybe OpenBSD, FreeBSD) or (Solaris, Linux). This way I could simply shutoff the vulnerable path when there's an unfixed vulnerability.

[1] https://youtu.be/rRg2vuwF1hY?t=264

[2] https://vez.mrsk.me/freebsd-defaults.html

===

BTW, I have the FreeBSD hardening and setup scripted, which you could add into the ISO in `/etc/installerconfig`, or downloaded from the orchestration and manually ran with `bsdintall script myinstallerconfig.sh` if you wish.

FreeBSD does not have a focus on security[0]. Indeed, the defaults are notoriously insecure. There was a textfile floating around on how to bring it up to some standard but it eludes me. So it’s a low bar, but freebsd is great under low memory conditions, it has a rock solid filesystem baked in that is gold-supported, one of the best tracing tools known to mankind and very clear documentation.

That’s the power of freebsd. Not security.

[0]: https://vez.mrsk.me/freebsd-defaults.html

Principles I wish FreeBSD would adopt from OpenBSD:

- turning all services (except ssh) off, by default

- moving all non-core things out of the base, like sendmail

- the base should only one way to do things (don’t have 3 different firewalls in base)

- changing poor defaults, https://vez.mrsk.me/freebsd-defaults.html

Note: there’s lots of things I wish OpenBSD would adopt from FreeBSD, like modern file system and much more.