Package: tor Version: 0.2.8.9-1 Severity: normal When running a tor hidden service, it's desirable to run it as a different user than debian-tor, and it's safer to use a unix socket than it is to run the hidden service on a localhost port. However, when a unix socket file is used for communication between tor and the hidden service, there is no good location to put it in. I suggest providing such a location.
It seems that /etc/apparmor.d/system_tor is used by default on systemd systems -- it appears to be limiting here what tor can read, although I don't have apparmor packages installed. In that file, tor is locked down to only be able to access /var/lib/tor/, /var/run/tor/, and /etc/tor/ /var/lib/tor is only readable by debian-tor, so for the hidden service socket to be located somewhere in there, the hidden service would have to be run as debian-tor (user or group). /var/run/tor is world readable, so it would be possible to make a subdirectory, say /var/run/tor/hidden_service/, allow the hidden service user to write to the subdirectory so it can bind the socket, and tor would be able to use it. But, /var/run does not persist across reboots, so this subdirectory would need to be set up on each boot by root before the hidden service starts up. /etc/tor is the only other option. Indeed, /etc/tor/hidden_service/ can be set up to be writable by the hidden service user, it can put its socket there, and tor can read it. But putting a socket in /etc/ is a FHS violation. I am using tor hidden services for P2P communication between git-annex repositories. The user runs a command as root once to set up the hidden service for their repository. So my current choices to integrate this with Debian's tor package are: * Violate the FHS by putting a non-config file in /etc/tor/ * Modify the apparmor config shipped with tor to let it read the socket in some other location. Seems this would require restarting the tor daemon amoung other complications. * Add an init script that sets up subdirectories under /var/run/tor with appropriate owners on boot. Complicated. So, the configuration of this package is encouraging me to violate the FHS. It seems like the most robust and simplest way. I suggest that the Debian tor package include a world-readable directory, which tor is allowed to access by its apparmor config and any other things used to lock it down. Subdirectories can then be added as needed to contain hidden service unix sockets, etc. (Another use case for such a world-readable directory could be onionshare. It currently uses a HiddenServiceDir in /tmp/onionshare/, so that it can read the onion address from it, which it could not if it used /var/lib/tor. /etc/apparmor.d/torbrowser.Tor.tor has a special case for that onionshare directory. This is why the onionshare package depends on torbrowser-launcher; see #762890.) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tor depends on: ii adduser 3.115 ii init-system-helpers 1.46 ii libc6 2.24-5 ii libevent-2.0-5 2.0.21-stable-2.1 ii libseccomp2 2.3.1-2 ii libssl1.0.2 1.0.2j-4 ii libsystemd0 232-3 ii lsb-base 9.20161101 ii zlib1g 1:1.2.8.dfsg-2+b3 Versions of packages tor recommends: ii logrotate 3.8.7-2 ii tor-geoipdb 0.2.8.9-1 ii torsocks 2.2.0-1 Versions of packages tor suggests: pn apparmor-utils <none> pn mixmaster <none> pn obfs4proxy <none> pn obfsproxy <none> ii socat 1.7.3.1-1 pn tor-arm <none> ii torbrowser-launcher 0.2.6-2 -- Configuration Files: /etc/tor/torrc changed [not included] -- no debconf information -- see shy jo
signature.asc
Description: PGP signature
