Description of problem: systemd doesn't allow tor to access /var/lib/tor/hidden_service/ Version-Release number of selected component (if applicable): Tor version 0.2.6.10 (git-58c51dc6087b0936). How reproducible: always Steps to Reproduce: 1. Uncomment a Hidden Service definition in /etc/tor/torrc 2. run systemctl start tor Actual results: Tor fails to start with the following messages: [notice] Tor v0.2.6.10 (git-58c51dc6087b0936) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1k-fips and Zlib 1.2.8. [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning [notice] Read configuration file "/usr/share/tor/defaults-torrc". [notice] Read configuration file "/etc/tor/torrc". [warn] Directory /var/lib/tor/hidden_service/ cannot be read: Permission denied [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details. [err] Reading config failed--see warnings above. Expected results: Tor should start without error and create a hidden service. Additional info: It should be noted that this is different from bug #1250893, because no selinux denials are generated. The error also appears when selinux is not enforcing. I also tried starting tor by hand with the same command line that systemctl uses: /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc ...and it worked. So the problem seems to be with the hardening section of the unit file of systemd.
Thanks for reporting! I'm able to replicate. Though in my tests, removing CapabilityBoundingSet is not enough by itself. SELinux also prevents Tor from running. The problem is due to the restrictive permissions on /var/lib/tor. I notice that Debian fixed this issue on Stretch/Sid by giving Tor CAP_DAC_OVERRIDE, CAP_CHOWN and CAP_FOWNER. These dangerous capabilities are effectively equal to root, and kind of defeats the point of using CapabilityBoundingSet in the first place. My alternative solution is to relax the permissions on /var/lib/tor, allowing group read and not complaining if permission is toranon:root instead of toranon:toranon. See the patch below for more explanation. Builds will enter updates-testing shortly. In the meantime, Koji builds available here. f23 https://kojipkgs.fedoraproject.org//packages/tor/0.2.6.10/5.fc23/x86_64/tor-0.2.6.10-5.fc23.x86_64.rpm f22 https://kojipkgs.fedoraproject.org//packages/tor/0.2.6.10/5.fc22/x86_64/tor-0.2.6.10-5.fc22.x86_64.rpm el7 https://kojipkgs.fedoraproject.org//packages/tor/0.2.6.10/5.el7/x86_64/tor-0.2.6.10-5.el7.x86_64.rpm From ec35ad51e585023b718c2b257721bdf2d2f25f3e Mon Sep 17 00:00:00 2001 From: Jamie Nguyen <j> Date: Mon, 9 Nov 2015 07:38:19 +0000 Subject: [PATCH] Create DataDirectory with group read permissions Directories created by Tor have 0700 and toranon:toranon permissions. Tor also checks the permissions again at runtime, reducing the permissions if they aren't 0700 and refusing to run if the owner or group aren't both toranon. These precautions protect the security of the Tor files. However, these permissions make the Tor DataDirectory (ie, /var/lib/tor) unreadable by the root user. When Tor is started as root, it accesses the DataDirectory before dropping root permissions. Normally this wouldn't cause any problems, but there are two situations in which Tor is prevented from running: (1) If the systemd CapabilityBoundingSet option is set but CAP_READ_SEARCH isn't listed, root is denied access to the Tor DataDirectory. (2) If SELinux is enabled but tor_t domain isn't allowed dac_read_search permissions, root is denied access to the Tor DataDirectory. CAP_READ_SEARCH and dac_read_search should be avoided; a process with these permissions can read arbitrary files regardless of DAC permissions. The solution proposed in this patch is to default to creating the DataDirectory with 0750 permissions, while also allowing the group to be either toranon or root. --- src/common/util.c | 2 +- src/or/config.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/common/util.c b/src/common/util.c index 442d57a..793fbb4 100644 --- a/src/common/util.c +++ b/src/common/util.c @@ -2196,7 +2196,7 @@ check_private_dir(const char *dirname, cpd_check_t check, return -1; } if ( (check & (CPD_GROUP_OK|CPD_GROUP_READ)) - && (st.st_gid != running_gid) ) { + && (st.st_gid != running_gid) && (st.st_gid != 0)) { struct group *gr; char *process_groupname = NULL; gr = getgrgid(running_gid); diff --git a/src/or/config.c b/src/or/config.c index fca350c..5cefc7c 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -1152,7 +1152,8 @@ options_act_reversible(const or_options_t *old_options, char **msg) /* Ensure data directory is private; create if possible. */ if (check_private_dir(options->DataDirectory, - running_tor ? CPD_CREATE : CPD_CHECK, + running_tor ? + CPD_CREATE|CPD_GROUP_READ : CPD_CHECK|CPD_GROUP_READ, options->User)<0) { tor_asprintf(msg, "Couldn't access/create private data directory \"%s\"", -- 2.5.0
tor-0.2.6.10-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-3b10fe315d
tor-0.2.6.10-5.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-488e7e1ea3
tor-0.2.6.10-5.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-c8974b11be
Now also reported upstream: https://trac.torproject.org/projects/tor/ticket/17562
tor-0.2.6.10-5.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'yum --enablerepo=epel-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-c8974b11be
tor-0.2.6.10-5.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-488e7e1ea3
tor-0.2.6.10-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update tor' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-3b10fe315d
Wow, thanks for such a prompt response and fix! Installed from updates-testing, confirmed it works.
*** Bug 1250893 has been marked as a duplicate of this bug. ***