Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] Tor Control Port in Tails
Rafael Bonifaz: > Hello,
> Last time I wrote to this list was related to the Mumble + Tails
> scripts. Here in CAD we have been working on GUI client that
> integrates Mumble and Tor Onion Service. The GUI is very simple you can
> host meetings and join meetings.
> At the moment we have a client that works in most modern Linux
> distributions and you can see the source.
> We also have a website, where you can download the binaries (of course
> that website needs a lot of work).
Cool! Tails really lacks a VoIP solution!
It's worth mentioning that we have been working on something similar through the Tails server project, basically a GUI with a list of predefined services that users can set up to be hosted via hidden service via essentially "one click", as well as a way to easily share the corresponding client configuration . Sadly that project has halted (since ~2018), I think because its flagship service, namely Mumble (well, its server murmurd to be specific), worked so poorly (over Tor) that it in the end made us hesitate whether we wanted to expose users to such poor UX. Do you not share this experience? Do you find that Mumble works well over Tor these days? In those tests, was murmurd hosted/accessed through a hidden service?
 If you are interested, the images attached to this ticket should give you a decent idea of how it works: https://redmine.tails.boum.org/code/issues/15300 > We want it to work in Tails, however we are not sure how to manage the
> control port in Tails. On Linux we start a new instance of Tor that we
> can control and use the AuthCookie to manage to the Control port.
> In Tails we can not do that as it would end in running Tor over Tor. Do
> you have advice on how we can have access to manage the control port so
> that we can create Onion Services?
For security reasons we created a custom filter, onion-grater, which allows you to define very precise access control rules how it can be used in a specific context. Basically you can make rules like "the binary /usr/bin/wahay when run under the amnesia user is allowed to send the command GETINFO but only with arguments matching the ip-to-country/\d+\.\d+\.\d+\.\d+ regular expression" (it uses a whitelist approach, so by default everything is forbidden).
You can find examples of such filter rules in /etc/onion-grater.d/ and hopefully the documentation inside the script itself, /usr/local/lib/onion-grater, is enough to allow you to write your own . If not, I'm happy to be of assistance! To make your life easier onion-grater can be started with the --complain option which will disable filtering (i.e. all control port access is allowed) while logging exactly what is going on, which you then can try to condense down to appropriate rules.
 In its own repo, https://git.tails.boum.org/onion-grater, there's a slightly improved documentation (also extracted to its own man page) that might be easier to read, although IIRC there is a difference that the "apparmor-profiles" key was renamed to "app-targets".
Cheers, and good luck!
This message was posted to the following mailing lists: