You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently in the process of standardizing on "BSD by default" for my growing fleet of four modest Tor middle relays. I appreciate the very straightforward reasons expressed so well by the Tor BSD Diversity Project and I’ve picked up on that as a way to start working on my own Linux monoculture. It seems like I currently run the only two BSD-based Tor relays in Finland (edit: this is not true at all, there are a handful. Looked through a list very sloppily!).
I particularly enjoy FreeBSD and the in-place upgrade path offered through ‘freebsd-update’.
Recently, I’ve been curious about HardenedBSD, as this fork fills in some of the odd blanks in FreeBSD, such as a PaX-like implementation of ASLR. I’m looking forward to their upcoming FreeBSD 11.0-RELEASE based release.
So, my question as an enthusiast, non-CS person: is HardenedBSD likely to mitigate any tangible risks of Tor relays being compromised through known or unknown vulnerabilities? That is, when compared to running vanilla FreeBSD and always applying relevant OS and Tor patches in a timely fashion.
Or are HardenedBSD's benefits in the case of Tor on a dedicated machine or VM small enough to be outweighed by the potential hassle of relying on the continuity and QA of a new project?
Maybe I’m overthinking this, but I find platform choices like these to be interesting dilemmas.
The text was updated successfully, but these errors were encountered:
The same arguments the Tor BSD Diversity Project apply to running Tor on HardenedBSD. Ridding a complex set of systems of monocultures is a good thing. If there are low-level vulnerabilities (like buffer overflows, format string vulnerabilities, etc.), they will certainly be harder to successfully exploit on HardenedBSD versus FreeBSD. We compile Tor as a PIE and with RELRO + BIND_NOW by default, so you'll get the full benefit of all the exploit mitigations HardenedBSD has to offer.
Additionally, you could run Tor within a jail. We're working on hardening system calls and sysctls such that ones that give out potentially sensitive information about the host to the jail are disallowed in the jail. A good example would be kldstat(8), which will not return any results to any users within a jail (including the jailed root user). In case Tor is successfully exploited, the system hardening techniques we are developing will help keep the host secure.
TL;DR: You have nothing to lose by running Tor on HardenedBSD.
This is fairly meta, but why not.
I'm currently in the process of standardizing on "BSD by default" for my growing fleet of four modest Tor middle relays. I appreciate the very straightforward reasons expressed so well by the Tor BSD Diversity Project and I’ve picked up on that as a way to start working on my own Linux monoculture. It seems like I currently run the only two BSD-based Tor relays in Finland (edit: this is not true at all, there are a handful. Looked through a list very sloppily!).
I particularly enjoy FreeBSD and the in-place upgrade path offered through ‘freebsd-update’.
Recently, I’ve been curious about HardenedBSD, as this fork fills in some of the odd blanks in FreeBSD, such as a PaX-like implementation of ASLR. I’m looking forward to their upcoming FreeBSD 11.0-RELEASE based release.
So, my question as an enthusiast, non-CS person: is HardenedBSD likely to mitigate any tangible risks of Tor relays being compromised through known or unknown vulnerabilities? That is, when compared to running vanilla FreeBSD and always applying relevant OS and Tor patches in a timely fashion.
Or are HardenedBSD's benefits in the case of Tor on a dedicated machine or VM small enough to be outweighed by the potential hassle of relying on the continuity and QA of a new project?
Maybe I’m overthinking this, but I find platform choices like these to be interesting dilemmas.
The text was updated successfully, but these errors were encountered: