HardenedBSD August 2023 Status Report

[Shawn Webb]

Hey all,

August was an interesting month. We updated the core networking components
(firewall, switch, cabling) to support 2.5Gbps internally. This will enable us
to grow to handle additional internal network load. The NICs in the servers
still need to be updated to 2.5Gbps, but that will come with time.

FreeBSD created the stable/14 branch. Shortly afterward, I followed along and
created the hardened/14-stable/master branch for HardenedBSD. We do not have the
build infrastructure in place for 14-stable, but will soon. I need to order new
SSD drives to increase capacity on one of the build servers. Afterwards, I'll
build the necessary VMs. I suspect it will take another month or so for the
hardened/14-stable/master build VMs to be brought up.

Speaking of the next month or so, I also plan to move hbsdfw's src tree to
14-stable in September.

In January, I plan to merge the hardened/current/cross-dso-cfi branch into
hardened/current/master. Between now and then, I need to determine how best to
get DTrace working again with Cross-DSO CFI. Please let me know if you require
use of DTrace in hardened/current/master. Letting me know usage patterns will
help me best determine my own priorities.

So, let's get into the src changes:

1. hbsd-update was taught how to regenerate the default HTTPS root trust store.
2. unbound-host(1) build in hardened/current/master was fixed.
3. Two sysctl knobs were hardened:
A. vfs.lookup_cap_dotdot (old default: 1, new: 0)
B. vfs.lookup_cap_dotdot_nonlocal (old default: 1, new: 0)
4. Memory permission transition code was debugged and some fixes committed.
There might be one more change needed to fully address this.

There was only two changes of note in the ports tree: Update ports-mgmt/pkg to
1.20.6 and a HardenedBSD-specific change to ftp/curl.. After getting my research
network back online, it appeared that pkg could not resolve .onion addresses
anymore. I knew that the pkg 1.19.x line could. FreeBSD switched pkg from
libfetch to libcurl with the 1.20.x line. In March of this year, libcurl
introduced code rejecting (with no possibility of override) resolutions of
.onion addresses. This means that on my research device (running HardenedBSD),
I could no longer update packages.

I reverted the prohibition on Tor Onion Services within both the libcurl
embedded in the pkg source code, updating the ports-mgmt/pkg and ftp/curl ports.

Now that the prohibition on resolving .onion addresses has been removed from pkg
and libcurl, I was able to verify direct access into our infrastructure through
our Tor Onion Services.

So, if you have configured Tor as a transparent proxy, you can continue using
curl/libcurl like normal on HardenedBSD. As a project, we believe everyone
should have equal access to resources. Placing non-optional arbitrary
restrictions in yet another monocultured ubiquitous project harms more than it
helps. We encourage application developers to implement toggles should they be
deemed appropriate. Firefox provides a good example here by providing an easy
toggle (the "network.dns.blockDotOnion" option in `about:config`).

The LAYLO mirror in the Netherlands stood up a Tor Onion Service endpoint for
their mirror:
http://zqsjg25lnx7zratmne3dhbcqt5paehitom3qp2rjmwttuy7gzbzqwayd.onion/pub/hardenedbsd

We are grateful to the community for their continued support of HardenedBSD.
Your contributions, no matter the form in which they come, are noticed and
greatly appreciated.

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc