A better list would start with design techniques and assurance activities that led to systems with few to no vulnerabilities during pentests by well-funded, knowledgeable attackers. That's on top of what survives in the field with lots of attention. In the 80's-90's, those techniques included precise specifications of behavior or security policy, ways of proving/testing that in the code, hierarchical layering with simple coding to facilitate analysis, small kernels with most code deprivileged, memory-safe languages where possible, verification that object code matches source w/ no compiler errors/subversions, partitioning GUI's/filesystems/networking limiting apps effects on each other, covert channel analysis of entire system, secure repo's containing these artifacts w/ secure transfer to users, and option to re-run the analyses or rebuild the kernel themselves for independent replication.
Each of these techniques found or prevented many vulnerabilities in systems they were applied to. They even became mandatory requirements under the first, security certification: the TCSEC. Trusted Xenix in 1990 used some of them for that reason. Unlike often-bypassed mitigations, each of these methods still work today. Some work even better due to tooling improvements. The BSD's are largely ignoring these methods to maintain legacy compatibility with insecure architecture, unsafe code, and configuration scripts that can be just as risky. Unsurprising given early attempts at applying strong methods to UNIX, like UCLA Secure UNIX, showed the UNIX design had covert channels and such built in. You couldn't fully secure a UNIX without breaking legacy compatibility in lots of ways on top of a significant performance hit from memory safety and context switching. Led high-security projects to just virtualize UNIX/Linux on top of secure, isolation kernel. Projects that are attempting to follow some of these lessons in low-privilege architecture or language use include GenodeOS, Muen separation kernel, seL4, JX OS, and ExpressOS for mobile. EROS was an interesting older one that added persistence on top of capability-based kernel.
I figure someone should mention the methods that stopped NSA's hackers in various evaluations since they're strangely not on the list.
This list is also not very accurate either: his ASLR patches to FreeBSD were rejected due to quality issues, then they were applied to HBSD. The lack of mark for base sandboxing is another one, where FreeBSD had Capsicum sandbox available for few years now and a lot of base is now Capsicum sandboxed, with more and more coming with every release. I could go on here, but that should give you the picture.
Take this advice with grain of salt as well - I'm a FreeBSD developer, so I might be biased.
It's not clear that all these features impact real-world security, but maybe I'm just inexperienced and naive. For example, OpenBSD has "Most of base sandboxed", which seems like a huge deal to me. Knowing how many security issues we've seen in the last 10 to 20 years relating to each feature would help in understanding their impact a lot more.
Some immediate questions that popped up from clicking through their pages: Who uses this OS? There's a few company links, but I had a hard time figuring out what some of them even do. Maybe this is a really dumb question, but why FreeBSD over OpenBSD? Finally, are changes being upstreamed? Can we expect these improvements to eventually make it into FreeBSD?
One downside with OpenBSD is the result of lacking resources - they only support the latest 2 releases (one every 6mo) with only the most critical patches being back ported. I don't believe syspatch(8) changes this, although its certainly easier to apply kernel patches now (please correct me if I'm mistaken)
Same with packages - unless you use mTier to get binary updates, security fixes and updates for packages need to be compiled yourself. Not the worst, but depends how much free time you have to keep on it.
FreeBSD has a larger ecosystem, and seems to be more performance oriented
And here I was thinking that pledge(2) was the sandbox. Did I miss something?
Pledge allows a program to 'promise' which calls it is expected to make. For example, a program promising only to use 'stdio', will SIGABORT if you try to open a socket, fork, exec, or anything not part of the stdio group (as defined by pledge)
Also, yes, syspatch makes the paching between releases a five seconds task.
This really makes it hard to use on AWS.
Because people need things other than security to actually do useful things with computers :)
- more ports
- more features (ZFS, DTrace, Jails, RCTL/RACCT, netgraph, Capsicum, CloudABI, Linuxulator)
- more drivers (lots of >=10GbE NICs, AMD GPUs, evdev for input devices)
- more SMP scalability (even NUMA work is ongoing on FreeBSD, while OpenBSD still has lots of things under giant lock AFAIK)
If you are just reading the slides, they are too out of context.
NetBSD: NIST CTR_DRBG using AES-128
Dragonfly BSD: xor of outputs ChaCha20 and IBAA
I don't have the time to analyze privsep in base among the BSDs, but I can say it's extensive in OpenBSD.
I would love to see pledge support in HardenedBSD. I think they're doing good work. Hopefully FreeBSD can import some of it.
Also, Dragonfly is a first-class BSD citizen and should be included in comparisons. As a recent example, the project leader, Matthew Dillon, has done excellent work relating to Speculative Execution and collaborated with other BSDs which helped everyone. Also I'm pretty sure OpenBSD has imported a number of hardware drivers from Dragonfly.
Kernel random (read_random_uio(9) / sysctl kern.arandom / /dev/*random / getrandom(2) / getentropy(3)) has been Fortuna since v10, and Yarrow before that.
If I am not mistaken, NetBSD uses ChaCha20 since 2015.
So NetBSD uses AES-128 in /dev/*random and ChaCha20 in arc4random(). I wonder why?
Recently I've become accustomed to seeing overly tuned feature lists where the product in question has, apparently, all the things you could want.
Any actual features that support your cynicism?
No JIT then?
I could see a locked down server process wanting to drop access to this, but I feel like it's unreasonable to have on by default. (Also looking at you, Apple.)
I just finished setting up a number of simple dev/test environments for a simple jdk8-based backed service, on DragonFly 5.2.2, using default DF configs. So wanted to understand what I might need to look for hardening (I am still rather far from production, though) ).
It will be enabled by default by the next release apparently.