I'm not GP, but yes. They do not work properly and likely introduce additional vulnerabilities.

Do you have any evidence for this? I've heard rumors here on HN and else where that HardenedBSD's code quality is lacking and that they didn't incorporate all the fixes and suggestions from the FreeBSD community during the various code reviews. But none of that is definitive, do you have any proof or evidence for this statement, "They do not work properly and likely introduce additional vulnerabilities."

Here's an example of poor code quality:

https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf...

If this check did anything, it appears susceptible to time-of-check, time-of-use attack.

See also https://reviews.freebsd.org/D473 , where Shawn pretty cleary does not incorporate feedback from the FreeBSD community.

Fair enough. The more important part of my question: isn't there a focused effort to complete FreeBSD's security feature checklist?

No one is paying for completion of checkbox security features in FreeBSD. So the community is really only interested in effective mitigations and not checkbox features.

We would love to merge in Konstantin's ASLR work. Reviewers have pointed out performance issues and memory fragmentation issues, especially on 32-bit platforms, but it's still better than nothing. I think we should just merge it as is, maybe default to off on 32-bit platforms, and improve from there. With the intent to have it polished for 12.0-RELEASE.

One such mitigation receiving community attention is Capsicum. The Capsicum security sandbox is a viable way to constrain applications. Unlike OpenBSD's pledge, rights are limited on a file descriptor basis. It has been ported to Linux and DragonFlyBSD (although merged to neither). There has been a lot of work in FreeBSD lately to restrict base programs, especially setuid programs, using Capsicum.