Re: [Tails-dev] Persistent torrc [Was: Tails Server: updated…

anonym:
> segfault:
>> anonym:
>>> [...]
>>> One thing to note about the mumble-server script is the "little
>>> bind-mount trick" used to workaround Tor's AppArmor confinement. We
>>> won't have that problem, I think. I did that so that all things we want
>>> to make persistent for mumble-server lives in the same directory on the
>>> persistent media, i.e. both Tor's HS bits, and mumble-server's data. We
>>> certainly can do better by making these two separate, e.g. we make
>>> /var/lib/tor/hs persistent and store all HS bits there, and then make
>>> another directory outside of this persistent for the service
>>> configuration/data bits.
>>
>> I ran into this problem today.
>
> :)
>
>> To make it possible to use both ephemeral
>> services and persistent services at the same time, I can't simply add
>> all services to /etc/tor/torrc and make it persistent, because then
>> obviously all hidden services would be persistent. Sadly, we don't have
>> /etc/torrc.d yet. So instead I chose to use the
>> /usr/share/tor/tor-service-defaults-torrc for the persistent services
>> and /etc/tor/torrc for the ephemeral ones.
>
> I think you should immediately look elsewhere for a better solution.
> tor-service-defaults-torrc must not be made persistent for the same
> reasons torrc must no (e.g. new versions will change this file, which
> persistence will "hide"). I don't even think this solution is wortwhile
> to use temporarily while fixing other parts -- a main goal of this
> project is to have a nice solution for this.
>
>> I wrote some code to make single files persistent by creating a new
>> directory in TailsData_unlocked, moving the file into it and adding the
>> directory to the persistence.conf with type "link". I think this a
>> pretty ugly solution.
>
> It sounds ugly, indeed.

Right. Do you have any other idea to solve this problem of making single
files persistent?

>> Now the problem is that the AppArmor confinement doesn't allow Tor to
>> use this symlink, because it points to a file outside of the allowed Tor
>> directories.
>
> ACK, this was the "big" problem I had to fight with when playing with
> the mumble-server script.
>
>> I could make the whole directory /etc/torrc or /usr/share/tor
>> persistent, but this would make some other files persistent too. I think
>> it would be problematic if a future release contains important changes
>> on any these files. Actually, this would also be problematic if we only
>> make one of the torrc files persistent and there would be important
>> changes to it.
>>
>> I could make this persistence feature even more ugly by creating a
>> subdirectory in /usr/share/tor/, making this subdirectory persistent,
>> then creating a symlink to it to TailsData_unlocked, putting the
>> tor-service-defaults-torrc in it and adding it to the persistence.conf
>> with type "link" to link the tor-service-defaults-torrc to /usr/share/tor.
>
> None of this is good enough, IMHO, and I don't think we have to dive in
> to details why since there are good solutions.
>
>> I think the best way would be to implement the torrc.d feature and/or
>> the bind-mounting-regular-files feature.
>
> Among these I think hacking our own torrc.d feature is preferable, but I
> think there are a few other good solutions too:
>
> # torrc.d hack
>
> We have a wrapper that we *always* use to (re)start to, namely
> restart-tor [0]. We could simply add logic to it so that before starting
> tor, for each $line of all files in /etc/tor/torrc.d/*.conf, check if
> $line is already present in /etc/tor/torcc, and if not, append $line.
> It's not as refined as the upstream feature will be, but it'll serve our
> purposes for now, so I think it is good enough.
>
> [0] config/chroot_local-includes/usr/local/sbin/restart-tor

This way we would have to call restart-tor to add / remove a hidden
service, right? So this would actually restart Tor, but right now I use
"systemctl reload tor@default", which does not restart tor but still
adds / removes hidden services. I think reloading provides better UX,
because restarting Tor closes all circuits.

> # Maintain HiddenService{Dir,Port} lines in /etc/tor/torrc
>
> This is very similar to the torrc.d hack above, but this logic is in
> Tails Server instead. This is what the mumble-server script did,
> essentially, and the availability of this option is what made me say "We
> won't have that problem, I think" in the text you quoted from an earlier
> email of mine above. No torrc persistence is needed for this -- Tails
> Server's persistent configuration will contain all the parameters needed
> for knowing exactly which HiddenService{Dir,Port} lines that should be
> in /etc/tor/torrc. Therefore I think it's preferable to the previous option.

So you mean we shouldn't use the Tails persistence feature for this at
all and simply ensure the lines are present when starting a Tails
service, right? I didn't think about this before, but I think this would
work.

> # add_onion
>
> By using stem to communicate with Tor over the control port/socket to
> add the hidden services, just like onionshare does (which would be a
> good source for inspiration, code-wise), you don't need any torrc
> persistence just like in the previous approach. This is probably the
> most "proper" solution of these three (and requires implementing less
> logic on our side), and it might even be the easiest after you've
> familiarized yourself with the API. This seems like the best option to me.

Right. I didn't see this option either, but I think this would work too.
I will try this :)

Cheers