HardenedBSD

500 Followers
3 Following
320 Posts
Security-oriented derivative of FreeBSD. Primary goal is a clean-room reimplementation of the grsecurity patchset for the BSD community.
WWWhttps://hardenedbsd.org/
GitHubhttps://github.com/HardenedBSD/hardenedBSD
Wikihttps://github.com/HardenedBSD/hardenedBSD/wiki
Bug trackerhttps://github.com/HardenedBSD/hardenedBSD/issues
The #HardenedBSD May 2026 status report is out! Main topic of focus is our migration from #GitLab to #Radicle : https://hardenedbsd.org/article/shawn-webb/2026-06-01/hardenedbsd-may-2026-status-report
HardenedBSD May 2026 Status Report | HardenedBSD

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.

#infosec #FatGid

295485 – need a way to block zfs.ko from being autoloaded by tools like puppet and facter (FatGID Vuln / CVE-2026-45250)

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).

I've now written some documentation on how to bootstrap the larger #HardenedBSD repos (src and ports) with #Radicle : https://radicle.network/nodes/rad.hardenedbsd.org/rad%3Az4Aucnb2nozutuek6o8PC9YfaBeTm#contributing-to-hardenedbsd
Radicle Explorer

Explore the Radicle network

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`).

Radicle Explorer

Explore the Radicle network

#Sydbox is on #Radicle with ID rad:z38HCnbmcDegA2BMxuPaPRPMdp6wF seed it and share the love! Huge thanks to #HardenedBSD folks for seeding! #exherbo #linux #security #git

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.

HardenedBSD Officially on Radicle | HardenedBSD

I restarted the last #HardenedBSD 15-STABLE package build. Tons of ports failed due fetch due to the network issues. Starting it from an incremental state means it should be finished relatively quickly.
We're now mostly alive! IPv6 is having issues, so I've disabled that. But IPv4 access into the #HardenedBSD infrastructure now works.