Pinned post

Due to a drastic increase in spam/fraudulent accounts in our self-hosted gitlab, we now require an admin approval of new accounts.

After registering, please email netops[AT]hardenedbsd.org to have us activate your account.

bug report: radicle.network/nodes/rad.hard

Update the hardening(4) manual page

If writing mandoc is your thing, and you would like to contribute to HardenedBSD, please submit us a patch over .

If you're unfamiliar with Radicle, I can help step you through the initial process of getting started (on a HardenedBSD system, of course.) Getting familiarized with their User Guide is a good first step: radicle.dev/guides/user

is announcing a call for donations of enterprise-grade drives: groups.google.com/a/hardenedbs

Please reach out to @lattera here on the Fediverse or via email (`shawn.webb@hardenedbsd.org`) if you're able to donate.

Today is Security Advisory day. I will cherry-pick the fixes into the relevant quarterly branches today.

I will probably kick off new builds either tomorrow (Thursday) or Saturday.

HEADS UP: The ports tree has been force pushed. This has ramifications for those who use our ports git repository:

groups.google.com/a/hardenedbs

Official update on the 2026Q3 builds is out: groups.google.com/a/hardenedbs

This includes a slight detour to talk about adjusting our release engineering process to take into account an interesting security feature built into .

16-CURRENT 2026Q3 installer images and OS update published.

I am going to wait a little bit to let my body recover to do the Cross-DSO CFI and Pledge feature branches. I'll work on those next week. I'll make sure to base them on around the same time as the last update to our primary development branch (aka, 16-CURRENT) hardened/current/master.

15-STABLE 2026Q3 installer images and OS update published.

15-stable 2026q3 installer/update build process started. quarterly release for 15-stable should complete in around 24-48 hours.

I plan to start on the 2026q3 release engineering process this afternoon after the next autosync. I hope to have the builds published by the end of this coming weekend.

I'm supposed to start the quarterly release engineering process this coming weekend. that work might be delayed. I'll probably ssh into the build VMs and comment out the cronjob before this weekend.

mitigated SA-26:34 back in March 2023 with commit c7d6d4bb4874720d9dab1625df62c2ea6eeb9df5.

Correction to come soon regarding TIOSCTI. Sorry for the misinformation. Hopefully the text above, included for transparency, is rendered strikethrough.

FreeBSD SA-26:32 is not applicable at all to HardenedBSD.

This bug highlights a strength of one of the features that makes 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 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 is fully mitigated in by default: freebsd.org/security/advisorie

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 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 src tree, users can:

```
$ git clone rad.hardenedbsd.org/z2HLHXgL1x 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`).

Show thread
Show older

HardenedBSD's choices:

BSD Network

bsd.network is a *BSD-adjacent Mastodon Instance. We have a code of conduct.