[tor-relays] FreeBSD 11.1 ZFS Tor Image

[George]

Conrad Rockenhaus:
> On Sunday, February 25, 2018 3:05:00 PM CST George wrote:
>> Conrad Rockenhaus:
>>> Hello All,
>>>
>>> If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image
>>> that is fully configured and ready to run Tor. Right now it's an eight GB
>>> image, but I'm reducing the size by removing all of the extra stuff on it
>>> from the upgrade from FreeBSD 11 to 11.1.
>>
>> I think it's great to ease the implementation of Tor relays,
>> particularly on BSDs.
> 
> My main thought process behind trying to ease the implementation of BSD relays 
> is the fact that we should diversify what we have online within the network. 
> Most of our nodes are Linux. What if we have another vulnerability that comes 
> out that hits Linux specifically again?

Oh, absolutely. Completely valid and the reason for The Tor BSD
Diversity Project's existence.

It's even uglier with bridges than with public relays.  Our stats give
daily snapshots to back your point:

https://torbsd.org/oostats.html

> 
>>
>> However, I'd be wary of an image that I didn't build myself, personally.
>>
> That's your opinion. The AWS relay project was very successful. Numerous 
> people ran an image that they didn't build. Numerous people also run Docker 
> containers that they didn't build. Numerous people run Vagrant boxes they 
> didn't build. You have the right to be weary, but there's numerous people out 
> there who run other people's images everyday.

Yes, being wary should be a guiding principle IMHO.

I'm aware of the other image-based roll-outs, but I just wanted to add a
disclaiming comment.

Personally, I'm purely for bare-metal server solutions to minimize
(although it doesn't eliminate) external trust. I understand that images
from whatever method are a gateway, but caution is compulsory.

> 
>>> If you're interested in the image let me know. This image has been fully
>>> tested on OVH's Openstack infrastructure, so if you're interested in
>>> running it on their infrastructure, let me know and I can walk you
>>> through it, or you're more than welcome to host is within my cloud at
>>> cost (it's a low monthly rate and unlimited bandwidth).
>>
>> Another issue is that OVH is over relied upon for public nodes. It's the
>> leading ASN with almost 15%.
> 
> They're one of the few providers out there that allow exits. That's why 15% of 
> our exits are on OVH.

Yes, of course. However, you refer to the lack of diversity in operating
systems, but monocultures in providers/ASNs is another danger we should
be conscious of.

> 
>>
>> https://torbsd.org/oostats/relays-bw-by-asn.txt
>>
>> OTOH, I do think we (in particular BSD people) need to facilitate the
>> implementation of BSD relays, including for VPS services for those
>> looking to test the waters.
> 
> I completely agree.
> 
>>
>> The TDP wiki has a list of other BSD-offering VPSs, plus a script for
>> Vultur to build on OpenBSD. I tend to think using other people's scripts
>> that can be reviewed and hacked is a better gateway for new relay
>> operators than images.
> 
> It would actually be very easy to find tampering within a BSD operating system. 
> Again, you're welcome to your opinion, but this is no the first time an image 
> has been offered to assist people within in the network, and again, with your 
> view, let's get rid of the tor docker containers, the AWS AMIs, etc.

All hardware, all operating systems can be tampered with.  From network
cards to your shell.  That is an accepted reality.

IMHO think virtualization in the current trend is dangerous and should
be avoided, from clouds to docker. It's more code to have bugs, more
systems to patch and more trust to grant.

But I'm not looking to debate those larger (and very real) issues.

Quite bluntly, it's easier for an adversary to just provide compromised,
back-doored images than to crack AES, compromise hardware, etc. By no
means am I being accusatory towards you, and as I started my replies
with, I think you're raising a wildly valid issue, but full systems
provided by someone on a mailing list don't pass a reasonable sniff test.

g



-- 


34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180225/3db92d4c/attachment-0001.sig>