| WWW | https://hardenedbsd.org/ |
| GitHub | https://github.com/HardenedBSD/hardenedBSD |
| Wiki | https://github.com/HardenedBSD/hardenedBSD/wiki |
| Bug tracker | https://github.com/HardenedBSD/hardenedBSD/issues |
| WWW | https://hardenedbsd.org/ |
| GitHub | https://github.com/HardenedBSD/hardenedBSD |
| Wiki | https://github.com/HardenedBSD/hardenedBSD/wiki |
| Bug tracker | https://github.com/HardenedBSD/hardenedBSD/issues |
This #FreeBSD bug highlights a strength of one of the features that makes #HardenedBSD attractive: optional blocking of loading of kernel modules.
HardenedBSD provides a sysctl node: hardening.pax.kmod_load_disable. By default, it is set to 0, permitting loading of kernel modules. When set to 1, loading kernel modules is prohibited. When set to 2, loading kernel modules is prohibited and a reboot is required to permit loading kernel modules once again.
HardenedBSD also has a notion of "insecure/untrusted" kernel modules. Some kernel modules in base, most notably the #Linux syscall emulation layer known as the linuxulator, are explicitly marked as untrustworthy. Users wishing to use those kernel modules must explicitly tag them as trusted (hbsdcontrol pax disable insecure_kmod /path/to/kernel/module.ko). Only then will the kernel module be permitted to load (the hardening.pax.kmod_load_disable sysctl node does need to be set to 0).
These two features can help protect users against situations where kernel modules get autoloaded, like with puppet, ifconfig, zfs, and other tools.
This kernel vulnerability in #FreeBSD is fully mitigated in #HardenedBSD by default: https://www.freebsd.org/security/advisories/FreeBSD-SA-26:21.ptrace.asc
HardenedBSD does not permit ptrace(PT_REMOTE_SC) by default. In fact, multiple sysctl nodes must be toggled to even support ptrace. We have a separate sysctl node for performing syscalls over the ptrace boundary (hardening.prohibit_ptrace_syscall, default 1).
Today, we learned that folks do NOT need to deploy a full #Radicle node to `git clone` or `git pull` our repos.
Instead, folks can use `git` normally, but use the Radicle web endpoint. For example, to clone the #HardenedBSD src tree, users can:
```
$ git clone https://rad.hardenedbsd.org/z2HLHXgL1xevBNQsf8BmQW7MpJmtm.git HardenedBSD-src
```
The only downside is that users who go this route will not be able to submit issues or patches via the normal Radicle way (since issues are created with `rad issue open`).
The #HardenedBSD wiki is now on #Radicle: https://radicle.network/nodes/rad.hardenedbsd.org/rad:z4Aucnb2nozutuek6o8PC9YfaBeTm/tree/Home.md
RID: rad:z4Aucnb2nozutuek6o8PC9YfaBeTm
It's official, #HardenedBSD can now be found on the #Radicle sovereign code forge: https://hardenedbsd.org/article/shawn-webb/2026-04-26/hardenedbsd-officially-radicle
There's still a lot more work to be done, but we're now at a point where the repositories are usable.