[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ
#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@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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs