[tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--------------------------+-----------------------------------
 Reporter:  arma          |          Owner:  atagar
     Type:  enhancement   |         Status:  needs_information
 Priority:  Medium        |      Milestone:
Component:  Core Tor/Nyx  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+-----------------------------------

Comment (by wagon):

 > That was a bad idea (because it gives arm permissions to things that it
 doesn't need). The better idea is to add the-user-that-will-run-nyx to the
 `debian-tor` group, and then use the fact that the `ControlSocket` is
 reachable by anybody in the group so authentication can happen smoothly.
 Despite I agree with you, I have to say that the difference is not that
 big. Nyx has full control over Tor's configuration. Therefore, if user
 used to run Nyx is compromised, Tor is completely compromised too.
 Nevertheless, the damage can be less, if it caused by some unintentional
 error in the code (i.e. not by intentional exploitation of the
 vulnerability).

 > as the user that will be running nyx, run `sudo adduser $USER debian-
 tor` to add your user to the `debian-tor` group so it can reach Tor's
 `ControlSocket`
 I agree that there should be some recommended simple way to run nyx
 relatively safely for everybody. However, I have to warn you that neither
 `su` nor `sudo` is a safe way to elevate privileges in UNIX system. If
 user you use for running `su`/`sudo` is compromosed, all accounts
 accessible by him using `su`/`sudo` are compromised too.

 What would be actually the safe and recommended way to run Nyx? It does
 not require changing any groups or enabling socket authentication.
 Instead, do the following:
 1. Create separate user for administrative tasks. Use separate console
 (Ctrl+Alt+Fn) or separate X window to log in under this user. Never use
 this user to run potentially unsafe applications such as browser.
 2. Configure your firewall in such a way, that this administrative user
 can only access `127.0.0.1:9051` (block all other loop back connections
 and all non-TCP protocols, block all connections through any other network
 interface). You can use this user for other administrative tasks  too (it
 depends on your setup, but `ssh` to `root at localhost` can be the example).
 3. Run Tor as a system service that listens at `127.0.0.1:9051` as its
 `ControlPort`.
 4. Disable cookie authentication in `torrc` (we don't need it), but enable
 password authentication in `torrc`. If you curious about the reasons, read
 my explanation in
 [[https://trac.torproject.org/projects/tor/ticket/28295#comment:5|another
 comment]].
 5. Wait for atagar to add password authentication in `nyxrc`
 ([[https://trac.torproject.org/projects/tor/ticket/28295|#28295]]) or type
 it interactively during Nyx start up already now.

 This is a general approach. Don't allow your tor-browser to use
 `ControlPort`, because in this case compromised browser would compromise
 your anonymity too. Circuits connections will not be seen in tor-browser,
 use Nyx or `tor-prompt` for that instead. SubgraphOS developers proposed
 additional proxy between tor-browser and Tor, which can filter potentially
 dangerous requests to `ControlPort`, but their approach (as relying on
 extra application for anonymity-critical task) is less safe than what I
 suggest you here: rely only on well tested UNIX kernel mechanisms---
 firewall, its configuration (you can filter traffic by user), and users
 privileges separation.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25890#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online