[tor-talk] Review request: TorVM implementation in Qubes OS: Vidalia

[Abel Luck]

adrelanos:
>> Future Work  Integrate Vidalia
> 
> About Vidalia again... I was quickly reading my dev ticket again (
> https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/Dev#SHELLSCRIPTSVidaliabydefaultGraphicalGatewayWAITINGFORVIDALIA0.3.x
> ), why it's not yet integrated into Whonix.
> 
> Summary:
> 
> "One drawback with Vidalia 0.2.15 remains... As soon as you edit torrc
> with Vidalia (i.e. add non-obfuscated bridges, all comments in torrc get
> lost, i.e. comments how to add obfuscated bridges get lost.).
> 
> Solved in 0.3.2-alpha. I am waiting for 0.3.2."
> 
> Another issue was, that Vidalia is explicitly not designed to manage a
> system wide installed Tor. Vidalia can not start/stop a Tor instance, it
> has not started itself.
> 
> Vidalia will also not be able to edit /etc/tor/torrc out of the box,
> because Vialia gets started as user, while /etc/tor/torrc is owned by root.
> 
> I am not sure how to solve it best...
> 
> Running Tor/Vidalia as user is also not the best option, that would
> prevent "sudo service restart tor" (probable also the Fedora
> equivalent). Breaking "sudo service restart tor" and running Tor as user
> is bad, since it can not be updated with by the system apt-get (or the
> Fedora equivalent). (Imagine long running servers.)
> 
> I guess the best might be to have Tor managed by the system (apt-get...)
> and to start Vidalia as a user. To edit /etc/tor/torrc, Vidalia needs an
> exception to have write rights on that file. Vidalia's start/stop Tor
> feature will break, I don't know how that could be solved. You still had
> a Tor which is partially managed by gui and partially managed by cli.
> Relaxing permission on Tor's data dir further for Vidalia broke Tor.
> 
> However, in qubes-os that all might be simpler to solve. Tor/Vidalia get
> updated from dom0?

No, no, nothing is updated from dom0.  All these problems still apply to
Qubes.  A further problem is at tor runtime I need to detect the IP
address of the internal interface, so a static torrc doesn't work.

Moreover, wrt the New Identity button. With several client VMs, multiple
apps using different SOCKSPorts, the behavior of New Identity is confusing.
	Does pushing it tear down and construct new circuits for
	everything? Only the TransPort? Only X?

Vidalia is extremely useful however, so I need to find some way to
include it. I wonder if the "best" solution isn't to scrap Vidalia and
make something new?

Look at the NetworkManager architecture. It lets the user control system
settings through a client app and daemon. In our case Tor == the daemon
and Vidalia the client.

Of course Vidalia needs permissions to start/stop Tor, which is problematic.