[feature suggestion] Tor control protocol should listen on privileged UNIX domain socket and allow an unauthenticated administration there

I suggest that tor should by default listen on the UNIX domain socket (ex. /tmp/.tor-unix/ctl-privileged) in addition to it currently listening on the local address 127.0.0.1:9100

Socket /tmp/.tor-unix/ctl-privileged should be owned by root with restrictive permissions like 0700, and no authentication should be required from the users (root) connected to it.

Why this is needed: I created the service that needs to modify the torrc, and currently there is no way to do this in automated way due to the authentication requirement. So I still have to write the torrc file directly, risking that my changes will get lost.

The service starts as root, and by the virtue of this has an authority to modify anything on the system, including torrc, but it still needs the password to do this the "right" way, which is unreasonable.

Additionally, it would make sense to also maintain /tmp/.tor-unix/ctl UNIX domain socket with less restrictive permissions which would require an authentication much like 127.0.0.1:9100 does.

added component::archived/general priority::medium resolution::wontfix status::closed type::enhancement labels

I'm not seeing a compelling reason for this, given that CookieAuthentication exists, but maybe I'm missing something.

Cookie authentication requires this line in torrc: CookieAuthentication 1

Imagine this: package manager installs tor package (by default with no cookie authentication in torrc), then my service package. Then services are started automatically, how can my service change config? CookieAuthentication is not set, and I have to write torrc again.

So cookie authentication is not the same.

[ccing atagar since he does a lot of control port stuff]

Replying to yurivict271:

Cookie authentication requires this line in torrc: CookieAuthentication 1

Imagine this: package manager installs tor package (by default with no cookie authentication in torrc), then my service package. Then services are started automatically, how can my service change config? CookieAuthentication is not set, and I have to write torrc again.

This sounds like something that's the package manger/user's problem. In general I would be against adding something like this, unless it was runtime configurable and defaulted to off, defeating the purpose of adding this feature in the first place.

IMO it is not tor's business to dictate policy, and having a magical unix socket only for the superuser (which isn't the user tor is running as on a sane system), is dictating policy (a magical unix socket for the tor user is equivalent to enabling CookieAuthentication).

FWIW: https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-service-defaults-torrc

So cookie authentication is not the same.

Fair enough.

What do you envision happening if a user happens to run more than 1 tor instance on a given box, and how will you disambiguate the various directories under /tmp?

Trac:
Cc: N/A to atagar

In case there are many instances this is easily solved by factoring in their pid in the ctl socket name.

Package manager/user can't solve this problem. They run 'pkg install tor my-service && service tor start && service my-service start'. Where does the user or package manager come into play? This boils down to either changing the default for CookieAuthentication, or the need of the direct user involvement: change this file, add this line here, and that line there. It quickly becomes the rocket science when it doesn't have to be. Superuser ctl socket elegantly solves this problem. Xorg also typically keeps such socket, this is a common practice to operate through the UNIX sockets.

Tor opens local socket at 127.0.0.1:9100 by default. This should have been UNIX socket to begin with, because that would have been the most natural choice. Why choose local net when UNIX socket is obviously more functional for this. UNIX socket actually supports authentication credentials too, among other potentially useful things.

Replying to yurivict271:

In case there are many instances this is easily solved by factoring in their pid in the ctl socket name.

Ok.

Package manager/user can't solve this problem. They run 'pkg install tor my-service && service tor start && service my-service start'. Where does the user or package manager come into play? This boils down to either changing the default for CookieAuthentication, or the need of the direct user involvement: change this file, add this line here, and that line there. It quickly becomes the rocket science when it doesn't have to be. Superuser ctl socket elegantly solves this problem. Xorg also typically keeps such socket, this is a common practice to operate through the UNIX sockets.

Tor opens local socket at 127.0.0.1:9100 by default. This should have been UNIX socket to begin with, because that would have been the most natural choice. Why choose local net when UNIX socket is obviously more functional for this. UNIX socket actually supports authentication credentials too, among other potentially useful things.

I agree that a Unix domain socket is a fine and sensible default, if ControlPort was enabled by default. But, the standard behavior of tor, built from an official source package, or git for that matter is to disable the control port.

So, any tor instance that isn't "the one that Tor Browser runs" which has the ControlPort enabled at all is already running a non-standard configuration, including the Debian package that does the right thing. So, complain to the packager that got it wrong.

Maybe tor should provide a ControlPort instance out of the box, and if it does, sure, it should be an AF_UNIX socket on systems that have AF_UNIX. But it currently does not, and if things were to change that way, then what's the point of a magic superuser socket in the first place.

Replying to yawning:

Maybe tor should provide a ControlPort instance out of the box, and if it does, sure, it should be an AF_UNIX socket on systems that have AF_UNIX. But it currently does not, and if things were to change that way, then what's the point of a magic superuser socket in the first place.

Yes, tor should have always-on UNIX socket for ControlPort.

You are right, no need for the "magic" superuser socket when authentication tokens on UNIX socket work. Tor instance can learn the connected user credentials through it. Notable example of this is MySQL server.

So in short it should work this way:

• Same ControlPort protocol should be supported on the UNIX-domain socket (suggested name /tmp/tor/ctrl.)
• This socket is always on, unlike 127.0.0.1:9100 which is optional
• This socket reads user credentials of the connected users, and waives authentication for root. Otherwise authentication works the same.

This modification would be great for tor integration with other systems, particularly services.

I'm still firmly against having a control port instance running by default. That should be something that the packager/system administrator/user decides, and explicitly enables because the control port can do really nasty things to the running tor instance.

But I doubt I'll change your mind in this regard.

Replying to yurivict271:

So in short it should work this way:

• Same ControlPort protocol should be supported on the UNIX-domain socket (suggested name /tmp/tor/ctrl.)
• This socket is always on, unlike 127.0.0.1:9100 which is optional
• This socket reads user credentials of the connected users, and waives authentication for root. Otherwise authentication works the same.

Why does root get a pass at authentication?

Yes, root can get the credentials anyway fairly trivially, but that along isn't sufficient reason to allow this. If I'm running tor as the "tor" system user, or as myself, what business does "root" have at being able to trivially mess with my tor instance?

This seems like an utterly terrible idea, because it's encouraging people to run things as root that have no business being ran as root in the first place. If something like this ever landed in tor and was enabled by default, the first thing I would do on all of my boxes is to patch my tor to remove it.

This modification would be great for tor integration with other systems, particularly services.

Because what I totally want on my box is running random services that need to be launched as "root" just so it can talk to my tor instance.

Anyway, I'm done commenting on this ticket. I think my opinions on this are fairly clear, though it's basically up to nickm.

No, it isn't "encouraging" root, it is "allowing" root, because he is already allowed to do anything he wants by the system. By design there is no protection against root actions.

Root can already do it, the question is if tor allows root to do it the nice way, or root will have to keep writing files.

This is my particular app: https://github.com/yurivict/freebsd-vbox-to-tor

The service connects VirtualBox VMs to TOR. It starts as root (as all/most services on FreeBSD), and adds several DNSListenAddress and TransListenAddress instructions to torrc. It removes them when it stops. It works completely automatically. Installing the packages and starting the services is sufficient. Anything beyond this is a quirk, unnecessary user irritation. If every package will require adjusting some files, etc system will become completely unusable.

Trac:
Cc: atagar to atagar, mcs

So there are several parts to this proposal.

• First part is that ControlPort protocol should work through the UNIX domain socket, I don't think anybody can disagree that this is a better solution, compared to the localhost port.

There are two points that appear to cause disagreement here:

• whether ControlPort should be always on, by default
• whether root should be given the right of authentication-free operation

I believe both should be implemented, because both don't cause any security problems, and at the same time make tor to interface with other systems smoother.

I think the correct way to make this stuff work is via a controller that uses cookie (or password) authentication and exposes the functionality you want.

Right now, you could install https://carml.readthedocs.org/en/latest/ for example and do "carml cmd setconf 'foo=bar'". You can also pipe a series of controller commands through carml.

That likely isn't the only controller that can do similar things, but it shows the safer way to do this, which is to enable cookie authentication and use a controller that speaks that authentication.

Yes, cookie is good. But I still like the idea of auto-login for root (privileged login). Please note that MySQL server uses this, for ex.

Also please note, that cookie approach is inherently less secure, because cookie can be accidentally disseminated by root. Auto-login doesn't suffer from the same problem.

Also UNIX socket is a must.

Maybe tor should provide a ControlPort instance out of the box, and if it does, sure, it should be an AF_UNIX socket on systems that have AF_UNIX. But it currently does not, and if things were to change that way, then what's the point of a magic superuser socket in the first place.

Yes, tor should have always-on UNIX socket for ControlPort.

Really this ticket boils down to just this, 'please make the ControlPort/Socket on by default'. This is gonna be a tough sell. For a security focused application like tor making the control interfact opt-in makes tor safer by default.

As Yawning said, we're not in the business of dictating policy. Package managers are welcome to chose whatever default torrc they'd like. Feel free to ask them if you want a ControlSocket to be open by default. For the upstream project though we plan to keep this as-is unless Nick changes his mind (and from irc it sounds as though he's not inclined).

First part is that ControlPort protocol should work through the UNIX domain socket, I don't think anybody can disagree that this is a better solution, compared to the localhost port.

It does. See the ControlSocket option...

https://www.torproject.org/docs/tor-manual.html.en#ControlSocket

As for authetication, both Stem and txtorcon make this transparent. If you need an example for how to connect or authenticate via any method manually...

https://stem.torproject.org/faq.html#can-i-interact-with-tors-controller-interface-directly

Trac:
Status: new to closed
Resolution: N/A to wontfix

It does. See the ControlSocket option... ​https://www.torproject.org/docs/tor-manual.html.en#ControlSocket

Thanks! Apparently not many know about this.

closed