domain socket as HiddenServicePort target -- permissions!?
Hello gents, I'd like to use a unix domain socket as HiddenServicePort target so I can remove networking capabilities from my hidden service's server process. Tor does not connect to my socket, though. Tor's debug level logging does not show any (comprehensible) errors. This is very frustrating to debug! Because of the documentation of unix domain sockets in *other* parts of Tor, like ControlPort, SocksPort et. al., I suspect it is about permissions. How *exactly* are the requirements of ownership and permissions of the socket and its directory and why? This is totally under-documented! I've tried to look at the sources (https://trac.torproject.org/projects/tor/ticket/11485), but I could not make much sense of it. I've manage to somehow create a socket that worked, but firstly there are so many variables so for the love of gods I was not able reproduce it and secondly as far as I can recall that were perms that required elevated privileges to get them set, which is totally out of the question for production. I'd like to elaborate more on what did work, but I am truly lost! Version: Tor 0.2.7.6 (git-605ae665009853bd) TIA, Johannes
Hi Johannes, Johannes:
I'd like to use a unix domain socket as HiddenServicePort target so I can remove networking capabilities from my hidden service's server process. Tor does not connect to my socket, though. Tor's debug level logging does not show any (comprehensible) errors. This is very frustrating to debug!
Because of the documentation of unix domain sockets in *other* parts of Tor, like ControlPort, SocksPort et. al., I suspect it is about permissions.
How *exactly* are the requirements of ownership and permissions of the socket and its directory and why? This is totally under-documented!
A unix socket should be readable and writeable for the user under which you're running tor ("tor", "_tor" etc). As well as for the server (nginx or whatever). So you need some combination that provides 'rw-' access for all relevant users ("nginx"/"www", "tor"/"_tor"...). E.g. this can be accomplished by adding these users to some "onionservice" group or whichever you like. P.S. You can test connectivity with `curl` by running something like this: $ curl --unix-socket /path/to/socket http:/// -- Sweet onions, Ivan Markin
Hello Ivan, thanks for your reply. I am afraid you are describing a situation that you and I expect(ed) to be reality. But it is not. Test 0: INET socket, just to check basic connectivity of the .onion address. => works Test 1: Socket /tmp/hstest.socket with perms 0666. This is not a good idea, but could work. => It does NOT work. Test 2: Socket at /srv/hstest/test.socket; directory /srv/hstest has group of the Tor user, setgid set (02750), socket file correctly inherits the group of the Tor user and has perms 0660. This is a setup that I think is reasonable. * Confirmed via debug log, that the correct socket path is used. * Checked with a local unix domain http client, ran as the Tor daemon's user => works. * Checked via onion: => does NOT work. Test x: Some unknown ad hoc created set of directory layout, ownerships and permissions--using root privileges that will totally not be available to the daemon's user and in its chroot. Not reproducible, because of the magnitude of possible combinations, the inability to debug this via Tor's logging, lack of documentation and my current level of frustration ... => Worked. Somehow. Forgot how, because I didn't know what to look for. /rant Obviously there are some checks done by Tor on the socket, the containing directory or both. My question is: What *exactly* is checked and what is the rationale in this case in contrast to the rationale applied to the checks done for domain sockets at other functionality than HS? Cheers, Johannes On 06/15/2016 09:32 PM, Ivan Markin wrote:
A unix socket should be readable and writeable for the user under which you're running tor ("tor", "_tor" etc). As well as for the server (nginx or whatever). So you need some combination that provides 'rw-' access for all relevant users ("nginx"/"www", "tor"/"_tor"...). E.g. this can be accomplished by adding these users to some "onionservice" group or whichever you like.
P.S. You can test connectivity with `curl` by running something like this: $ curl --unix-socket /path/to/socket http:///
-- Sweet onions, Ivan Markin _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On 16 Jun (16:14:22), Johannes wrote:
Hello Ivan,
Hi Johannes,
thanks for your reply. I am afraid you are describing a situation that you and I expect(ed) to be reality. But it is not.
Test 0:
INET socket, just to check basic connectivity of the .onion address.
=> works
Test 1:
Socket /tmp/hstest.socket with perms 0666. This is not a good idea, but could work.
=> It does NOT work.
Test 2:
Socket at /srv/hstest/test.socket; directory /srv/hstest has group of the Tor user, setgid set (02750), socket file correctly inherits the group of the Tor user and has perms 0660. This is a setup that I think is reasonable.
* Confirmed via debug log, that the correct socket path is used.
* Checked with a local unix domain http client, ran as the Tor daemon's user => works.
* Checked via onion: => does NOT work.
Can you send the HiddenServicePort line that you use (you can obfuscate path and port) for the Unix socket. Then the "ls -al" of the Unix socket once created. Does the user or group of the Tor user has at least "w" access? Also, what do you mean by "Checked via onion" does NOT work? You tried to access the .onion and it doesn't reach the Unix socket? If so, one easy way would be to nc -u /tmp/some.sock -l and bind the HS to that socket. See if you get the data. If you get it, then the Unix socket application support is the issue, else we have another issue. I use extensively Unix socket for HS so I can tell you it works but the permissions are can be tricky. Thanks! David
Test x:
Some unknown ad hoc created set of directory layout, ownerships and permissions--using root privileges that will totally not be available to the daemon's user and in its chroot. Not reproducible, because of the magnitude of possible combinations, the inability to debug this via Tor's logging, lack of documentation and my current level of frustration ...
=> Worked. Somehow. Forgot how, because I didn't know what to look for.
/rant
Obviously there are some checks done by Tor on the socket, the containing directory or both. My question is: What *exactly* is checked and what is the rationale in this case in contrast to the rationale applied to the checks done for domain sockets at other functionality than HS?
Cheers, Johannes
On 06/15/2016 09:32 PM, Ivan Markin wrote:
A unix socket should be readable and writeable for the user under which you're running tor ("tor", "_tor" etc). As well as for the server (nginx or whatever). So you need some combination that provides 'rw-' access for all relevant users ("nginx"/"www", "tor"/"_tor"...). E.g. this can be accomplished by adding these users to some "onionservice" group or whichever you like.
P.S. You can test connectivity with `curl` by running something like this: $ curl --unix-socket /path/to/socket http:///
-- Sweet onions, Ivan Markin _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
Yeah, now I recall that on some systems with AppArmor/SELinux or on OpenBSD tor as other daemons has restictions applied on the paths accessible for them. Try to put your unix socket into tor's DataDirectory. At least it works for me on OpenBSD. David Goulet:
I use extensively Unix socket for HS so I can tell you it works but the permissions are can be tricky.
I'm also using Unix sockets a lot and can say that 'rw-' is enough for plain Linux. In other case note above. -- Ivan Markin
Ivan, David, thanks a lot! It works now. I've created more tests and wrote a huge, detailed, now deleted mail, but in the end it was this hint that brought me to the right track: On 06/16/2016 05:07 PM, Ivan Markin wrote:
Yeah, now I recall that on some systems with AppArmor/SELinux or on OpenBSD tor as other daemons has restictions applied on the paths accessible for them.
I use the tor project's debian package on the dev machine and it has some AppArmor profiles. After simply adding /srv/hstest/hstest.socket rw, to the file /etc/apparmor.d/local/system_tor and reloading AppArmor it works. Relieved, Johannes
participants (3)
-
David Goulet -
Ivan Markin -
Johannes