tl;dr: $ sudo apt install snapd; sudo snap install tor-middle-relay
Hi.
Ubuntu has been working on a new kind of software package* that aims for isolation from the rest of the system, so 1) anyone can create packages for others without review, 2) security is better, and 3) it can be the basis for lots of supposedly single-purpose systems like cars, watches, home security systems, etc. The packages work for desktop and server too.
The upshot is that soon, they hope, many devices will run the miniature Ubuntu plus the single package that makes the device do what it does to act like that device. If the mfr doesn't restrict it, we users can add other things that they never intended to make our device do more. Your Wifi Router could also be your print server. Why not?
I made a tor-middle-relay package, so the TVs, Wifi Routers, Toasters, Self-driving Cars, Phones... of the world that are running that new kind of Ubuntu (or other OS that implements this package system!) can also help the Tor network.
The code that enables that new package system is already in Ubuntu 16.04 LTS, so even existing desktops and servers can already use it.
So, if you use Ubuntu 16.04 LTS, this should get you a Tor relay
$ sudo apt install snapd $ sudo snap install tor-middle-relay
(The ARMHF architecture has an open bug where the new package security rejects the "personality" syscall that Tor calls, so ARMHF doesn't work out of the box right now.)
Once you have it installed, try $ sudo /snap/bin/tor-middle-relay.configure to bump up your bandwidth limit over the conservative defaults.
There are a few dozen users already. https://atlas.torproject.org/#search/UbuntuCore I'd be happy to have an explosion of devices all over the world.
Please send bug-reports privately, not to this list.
- chad
* https://developer.ubuntu.com/en/snappy/ http://snapcraft.io/
- security is better
Sorry to say that, but : no. It’s very weaker than plain old Debian package.
Currently, your snap embeds : libevent openssl pthreads libasan2 libubsan python 2.7 python-torctl tor-arm tor
Any security change on one of those embeded libraries require *you* rebuild and upload a new snap to fix the problem. This is very problematic for at least openssl (very frequent security fix) and tor/torctl/tor-arm (now, *you* need to follow every official releases of those 3 parts and deliver a new snap each time).
On a plain old Debian package, a security change impacts only *one* package (not *all* apps) and require only *the maintainer* of the lib package (not *all* apps ones) to rebuild and deploy. And this fixes *every* other package using this lib without extra step.
Snap, docker and more generally all packaging system embeding libs inside are just a nightmare in terms of security update.
<3
On Wed, Aug 24, 2016, at 16:43, Aeris wrote:
- security is better
Sorry to say that, but : no. It’s very weaker than plain old Debian package.
This is a matter of perspective on the "security" definition.
The snaps does run in a separate container group, so it does have some more layers of isolation to the rest of the system. This means it is probably better to install an untrusted snap than adding another untrusted APT source repository for your system.
Otherwise I agree with the library security updating problem.
-jv
This is a matter of perspective on the "security" definition.
Yep of course :P
For desktop-purpose, snap can eventually be interresting. You only put yourself at risk. For server-purpose, you also put your users at risk, and in case of Tor, it’s very safer for them to run Tor with at least OpenSSL & Tor up-to-date, and so to use and follow official upstream release.
<3,
On Wed, Aug 24, 2016 at 05:33:43PM +0200, Jan Vidar Krey wrote:
On Wed, Aug 24, 2016, at 16:43, Aeris wrote:
- security is better
Sorry to say that, but : no. It’s very weaker than plain old Debian package.
This is a matter of perspective on the "security" definition.
The snaps does run in a separate container group, so it does have some more layers of isolation to the rest of the system. This means it is probably better to install an untrusted snap than adding another untrusted APT source repository for your system.
That's great, except you _really_ shouldn't be installing an untrusted _anything_ on your system, much less an untrusted tor package. And implying that this system magically makes untrusted things safe and suitable for install on a working machine is in my opinion a terrible precedent to set. A malicious tor install can do plenty of harm even if it was fully isolated from the rest of the machine.
If something is untrusted, don't install it. Period.
--Sean
much less an untrusted tor package
For information, the tor binary inside the snap doesn’t match any official upstream I can find…
SHA1 Snap ba16ce2958119a238d7931e709f30e932938218f Xenial (tor_0.2.7.6-1ubuntu1_amd64.deb) 997b717acaf2077708beba39a05adb30c014dfb2 Debian Jessie backports (tor_0.2.7.6-1~bpo8+1_amd64.deb) cd63c5e01481a2b195bcb23c3d96dd81fb4f722d Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1_amd64.deb) f64cf21322c26372457cffcb7aeb97dd7768b697 Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1~d70.wheezy+1_amd64.deb) 6ba3b089029c1ae77ffcfb8fe2ee39335066b98a Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1~xenial+1_amd64.deb) 8a2387c986ae98df7b2b78463aa6104ae5ebd080
<3,
* Aeris aeris+tor@imirhil.fr [2016-08-24 19:25:31 +0200]:
much less an untrusted tor package
For information, the tor binary inside the snap doesn’t match any official upstream I can find…
SHA1 Snap ba16ce2958119a238d7931e709f30e932938218f Xenial (tor_0.2.7.6-1ubuntu1_amd64.deb) 997b717acaf2077708beba39a05adb30c014dfb2 Debian Jessie backports (tor_0.2.7.6-1~bpo8+1_amd64.deb) cd63c5e01481a2b195bcb23c3d96dd81fb4f722d Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1_amd64.deb) f64cf21322c26372457cffcb7aeb97dd7768b697 Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1~d70.wheezy+1_amd64.deb) 6ba3b089029c1ae77ffcfb8fe2ee39335066b98a Tor project repo (tor_0.2.7.6-dev-20160824T140713Z-1~xenial+1_amd64.deb) 8a2387c986ae98df7b2b78463aa6104ae5ebd080
Aeris, I should be worried if any of those matched. Did you know 0.2.8 is out?
Aeris, I should be worried if any of those matched. Did you know 0.2.8 is out?
Currently not on Xenial and Jessie (even in backport). ><
<3,
Ubuntu/Debian doesn't have the latest version of Tor. You should use the official repository: https://www.torproject.org/docs/debian.html.en
On Aug 24, 2016 12:50 PM, "Aeris" aeris+tor@imirhil.fr wrote:
Aeris, I should be worried if any of those matched. Did you know 0.2.8 is out?
Currently not on Xenial and Jessie (even in backport). ><
<3,
Aeris Individual crypto-terrorist group self-radicalized on the digital Internet https://imirhil.fr/
Protect your privacy, encrypt your communications GPG : EFB74277 ECE4E222 OTR : 5769616D 2D3DAC72 https://caf%C3%A9-vie-priv%C3%A9e.fr/ https://xn--caf-vie-prive-dhbj.fr/ _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Ubuntu/Debian doesn't have the latest version of Tor. You should use the official repository: https://www.torproject.org/docs/debian.html.en
I already use this repo for all my relays :)
<3,
Currently not on Xenial and Jessie (even in backport). ><
Don’t match 2.8.6 too :
snap ba16ce2958119a238d7931e709f30e932938218f ubuntu yakkety tor_0.2.8.6-3ubuntu1_amd64.deb 5839f7b8bdc74cc26c829452d458d5c797ff3666 official tor tor_0.2.8.6-3_amd64.deb 6f2f4118b69420882022b526b956d65dc22a0b12 official tor xenial tor_0.2.8.6-3~xenial+1_amd64.deb 98677a0bfd0d3c22f342b44b824ba4d03f8facd3
IMO, if you rebuild from scratch, you have to achieve reproductible build, to allow post-build verification (and so, trustability of your snap).
<3,
On Wed, Aug 24, 2016 at 09:47:56AM -0400, Chad MILLER wrote:
I made a tor-middle-relay package, so the TVs, Wifi Routers, Toasters, Self-driving Cars, Phones... of the world that are running that new kind of Ubuntu (or other OS that implements this package system!) can also help the Tor network. [...] Once you have it installed, try $ sudo /snap/bin/tor-middle-relay.configure to bump up your bandwidth limit over the conservative defaults.
Nice idea!
Other people here have very valid points about the security and maintability side of things, but I'll add another point: It looks like the conservative defaults you mention are a BandwidthRate and BandwithBurst of 75 KBytes.
That tiny level of rate limiting basically ensures that none of these relays will ever get the Fast flag, so they will never be used by actual users.
The current recommendation on https://www.torproject.org/docs/tor-relay-debian is to allow at least 250 KBytes/s each way. And even those will be tiny and rarely used compared to the bigger relays.
I wonder if your project would be better at producing bridges? https://www.torproject.org/docs/faq#RelayOrBridge Especially since you could include obfs4 (or even more!) support as part of the bundle.
--Roger
News: Package is at Tor 0.2.8.7, which was released yesterday.
* Roger Dingledine arma@mit.edu [2016-08-25 00:33:14 -0400]:
Nice idea!
Other people here have very valid points about the security and maintability side of things, but I'll add another point: It looks like the conservative defaults you mention are a BandwidthRate and BandwithBurst of 75 KBytes. That tiny level of rate limiting basically ensures that none of these relays will ever get the Fast flag, so they will never be used by actual users.
I had that same thought a few days ago. Thank you for the note. That's just the kind of feedback I wanted.
http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/revis...
I wonder if your project would be better at producing bridges? https://www.torproject.org/docs/faq#RelayOrBridge Especially since you could include obfs4 (or even more!) support as part of the bundle.
If you look at the atlas list, you'll see that about 1 out of four are bridges. At startup, it generates keys, and then uses the fingerprint to decide whether to volunteer to be a bridge relay for the rest of its life.
Built in are the obfs4 plugins, and also the firewall helper, and nyx/arm. Your "more!" intrigues me, though. Private mail?
* Green Dream greendream848@gmail.com [2016-08-30 21:39:34 -0700]:
chad> 1) anyone can create packages for others without review, 2) security
is better
These two concepts seem fundamentally at odds. Perhaps I have misunderstood you. How would unreviewed code be better for security?
Good question. It's better because it was beyond terrible before. "Security" means nothing without a lot of context, but maybe we can agree it means enforcement of some policy.
When you run a program in this packaging scheme, it is confined to a specific set of syscalls (seccomp), used in a specific few ways (apparmor), and through some mounting of filesystem images that don't even implement write() (squashfs) and bind mounts, it appears to itself to be the only program installed on an otherwise barebones linux machine with almost nothing writable execept a few data directories that it's informed of at run time. No matter what else is installed, it can't do much about it, and if it tries to get uppity, the kernel will likely slay it.
It gets access to previous versions of its data, so it could clobber that.
The packages I have here request "network bind" and "network" permissions, so a bad program could create sockets. (Which is nothing to sniff at!)
It could also steal resources like CPU time or RAM.
But it can never look in your ~/.gnupg/ dir or grab your scanner or wipe your yubikey or turn on your camera or whatever, as another program, rogue or compromised, could do. None of that even seems to exist.
This is a packaging system with dense policy built-in, and it's enforced so pretty much the only thing software can see is its own belly-button.
Reviewed code is great, but large swaths of code on our machines has had one or fewer very interested persons look at every line. And one line is all it takes to be catastrophic. Better to treat every program as guilty and untrustworthy. Design for untrustability instead of hoping for diligence.
Snap is not perfect, and it's not my baby, but I admire it.
On 31 Aug 2016, at 15:20, Chad MILLER chad@cornsilk.net wrote:
But it can never look in your ~/.gnupg/ dir or grab your scanner or wipe your yubikey or turn on your camera or whatever, as another program, rogue or compromised, could do. None of that even seems to exist.
If it shares physical RAM with other processes or VMs, it can modify their RAM, under certain conditions:
https://www.schneier.com/blog/archives/2016/08/powerful_bit-fl.html
Unfortunately, VMs and similar isolation techniques aren't great at preventing hardware-based side-channels.
But in most cases, for most threat models, yes, it's quite secure.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
tor-relays@lists.torproject.org
-
Aeris -
Chad MILLER -
Green Dream -
Jan Vidar Krey -
Roger Dingledine -
Sean Greenslade -
teor -
Tristan