Request for discussion: HardenedBSD 4-state sysctl tunables

[Shawn Webb]

Hey all,

Currently, HardenedBSD has a few sysctl tunables that are expected by
one of four states:

* 0: Disabled
* 1: Explicit Opt-In
* 2: Explicit Opt-Out
* 3: Force Enabled

I'm thinking of adding a new state:

* 4: Force enabled, must reboot to modify

This would make it somewhat more difficult for an attacker to
accomplish their goals, since reboots are generally considered "noisy"
events.

We have the notion of state integer 4 (reboot to modify) for the
hardening.pax.prohibit_new_usb sysctl tunable. However, in that case,
the values for the hardening.pax.prohibit_new_usb are:

* 0: Disabled
* 1: Enabled
* 2: Force enabled, must reboot to modify

That is all meant to say: we have the notion of this additional state
for one other HardenedBSD-specific sysctl tunable, so there is
precedent here.

Here is a list of the four-state sysctl tunables that would be
migrated to the proposed five-state:

* hardening.harden_shm
* hardening.pax.aslr.status
* hardening.pax.disallow_map32bit.status
* hardening.pax.mprotect.status
* hardening.pax.pageexec.status
* hardening.pax.sevgguard.status
* hardening.pax.tpe.status

Note that we won't be changing the default values, so this is going to
be a NO-OP ("nothing to see here, move along") for most
users/deployments.

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username: shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[Dewayne Geraghty]

I like the idea of protecting syctl's after the system has completed booting.  :)

I vaguely recall you asking for input re enhancing HardenedBSD via telegram, though I thought of locking down  all non-performance related sysctl's via something like securelevel=3+ :).

Perhaps a better approach is to use a sysctl to inhibit changing security.mac and hardening.pax, would be helpful against compromise. Your suggestion is a great starting point, thank-you for keeping your eye on improving BSD for us.

The other suggestion to improve HBSD, was placing a label on network packets entering the system.  Currently, when using MAC_MLS or MAC_BIBA, all packets are assigned a label via the interface (setting), a nice extension would be to label the packet as it exited ipfw or pf; particularly as there are so many jails listening to an interface, a (MAC) labelled packet would protect the packet from a compromised jail. 

My 2c :)

Kind regards, Dewayne.

[Shawn Webb]

On Sun, Jan 11, 2026 at 11:02:33PM +0000, Dewayne Geraghty wrote:
> I like the idea of protecting syctl's after the system has completed
> booting. :)

Awesome. I think this change from 4-state to 5-state sysctl nodes will
be pretty easy. I'm at the tail end of recovering from a sinus
infection, so I might work on this.

I try not to commit code when sick, but this easy enough that I
probably wouldn't make any grave mistakes. :-)

>
> I vaguely recall you asking for input re enhancing HardenedBSD via
> telegram, though I thought of locking down all non-performance related
> sysctl's via something like securelevel=3+ :).
> Perhaps a better approach is to use a sysctl to inhibit changing
> security.mac and hardening.pax, would be helpful against compromise. Your
> suggestion is a great starting point, thank-you for keeping your eye on
> improving BSD for us.

Just so you're aware, I don't use Telegram. If you've been conversing
with a Shawn Webb on Telegram, that is NOT me. And do please let me
know if you have been in contact with an impersonator (and when, if
possible).

>
> The other suggestion to improve HBSD, was placing a label on network
> packets entering the system. Currently, when using MAC_MLS or MAC_BIBA,
> all packets are assigned a label via the interface (setting), a nice
> extension would be to label the packet as it exited ipfw or pf;
> particularly as there are so many jails listening to an interface, a (MAC)
> labelled packet would protect the packet from a compromised jail.

I could see that being pretty useful. I wonder if that could be
implemented as a MAC module, or if the supported firewalls/packet
filters need to be modified as well.

I'm not an expert in the networking code. Networking stacks are pretty
complex and I'm not sure I'm the right person to do that kind of work.