Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:47:18Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32218Systemd problem with ExecReload and CAP_KILL2020-06-13T15:47:18ZTracSystemd problem with ExecReload and CAP_KILLHi
There is a known issue with CGroup hardening which systemd applies, that without CAP_KILL capability, it's not possible to send HUP signal by managed slice, even to MAINPID.
Please add it to CapabilityBoundingSet= section in unit file...Hi
There is a known issue with CGroup hardening which systemd applies, that without CAP_KILL capability, it's not possible to send HUP signal by managed slice, even to MAINPID.
Please add it to CapabilityBoundingSet= section in unit file.
Running Tor 0.4.2.2-alpha on Gentoo.
https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in?id=d5cbc58094ec740e768d5fa88a51c20c645ed70e
**Trac**:
**Username**: sunovaTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29621Systemd Tor service starts too early2020-06-13T15:38:48ZTracSystemd Tor service starts too early**Defect description:**
Tor 0.3.5.8 (.deb packages from deb.torproject.org) on Ubuntu 18.04 amd64 (systemd), starts too early during the boot process, (reproducibly) resulting in "Problem bootstrapping" messages:
```
$ journalctl --utc ...**Defect description:**
Tor 0.3.5.8 (.deb packages from deb.torproject.org) on Ubuntu 18.04 amd64 (systemd), starts too early during the boot process, (reproducibly) resulting in "Problem bootstrapping" messages:
```
$ journalctl --utc -b | sed -e 's/'$HOSTNAME'/myhostname/' -e 's/ Tor[\[0-9\]*]/ Tor[1234]/' | grep 'myhostname Tor'
Feb 28 17:17:42 myhostname Tor[1234]: Tor 0.3.5.8 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0g, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
Feb 28 17:17:42 myhostname Tor[1234]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 28 17:17:42 myhostname Tor[1234]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 28 17:17:42 myhostname Tor[1234]: Read configuration file "/etc/tor/torrc".
Feb 28 17:17:42 myhostname Tor[1234]: Opening Socks listener on 127.0.0.1:9050
Feb 28 17:17:42 myhostname Tor[1234]: Opened Socks listener on 127.0.0.1:9050
Feb 28 17:17:42 myhostname Tor[1234]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Feb 28 17:17:42 myhostname Tor[1234]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Feb 28 17:17:42 myhostname Tor[1234]: Bootstrapped 0%: Starting
Feb 28 17:17:43 myhostname Tor[1234]: Starting with guard context "default"
Feb 28 17:17:43 myhostname Tor[1234]: Signaled readiness to systemd
Feb 28 17:17:43 myhostname Tor[1234]: Problem bootstrapping. Stuck at 0%: Starting. (Network is unreachable; NOROUTE; count 1; recommendation warn; host A59B27226496443A93D25E8D87BFCB8ADEDB4862 at 51.75.125.233:9001)
Feb 28 17:17:43 myhostname Tor[1234]: Opening Socks listener on /run/tor/socks
Feb 28 17:17:43 myhostname Tor[1234]: Opened Socks listener on /run/tor/socks
Feb 28 17:17:43 myhostname Tor[1234]: Opening Control listener on /run/tor/control
Feb 28 17:17:43 myhostname Tor[1234]: Opened Control listener on /run/tor/control
Feb 28 17:17:43 myhostname Tor[1234]: Bootstrapped 5%: Connecting to directory server
Feb 28 17:17:43 myhostname Tor[1234]: Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 2; recommendation warn; host 617314F0CD8B8EA76B4963AC6C6BA3773DA63594 at 144.76.91.135:9001)
Feb 28 17:17:43 myhostname Tor[1234]: Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 3; recommendation warn; host A0F39D32028CEC7F35419E9570401DE15B1B4564 at 5.196.58.96:9001)
Feb 28 17:17:44 myhostname Tor[1234]: Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 4; recommendation warn; host BCC9FA5994200032E9CD04866B823B6D929F22A8 at 78.31.65.92:443)
Feb 28 17:17:45 myhostname Tor[1234]: Bootstrapped 10%: Finishing handshake with directory server
Feb 28 17:17:45 myhostname Tor[1234]: Bootstrapped 80%: Connecting to the Tor network
Feb 28 17:17:45 myhostname Tor[1234]: Bootstrapped 90%: Establishing a Tor circuit
Feb 28 17:17:47 myhostname Tor[1234]: Bootstrapped 100%: Done
```
**Impact:**
As seen, Tor does finally bootstrap successfully, and functionality is not impacted.
**Correction:**
This issue appears to be caused by imperfect service dependencies as set in /lib/systemd/system/tor@.service and /lib/systemd/system/tor@default.service:
```
[Unit]
After=network.target nss-lookup.target
```
My interpretation of the [systemd documentation](https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/) is that this should correctly say:
```
[Unit]
After=network-online.target nss-lookup.target
Want=network-online.target nss-lookup.target
```
I suspect that using "network-online.target" (instead of "network.target") may also allow for removing the "nss-lookup.target" dependency, but have not attempted to verify this.
**Related:**
* [ticket:25803#comment:6 Ticket #25803 "Infinite restart loop when daemon crashes", comment 6]
* [ticket:20930 Ticket #20930 "Use new systemd hardening options"]
**Trac**:
**Username**: tomreynhttps://gitlab.torproject.org/legacy/trac/-/issues/28410systemd restart loop when tor@default.service::Type=notify2020-10-30T02:28:54ZTracsystemd restart loop when tor@default.service::Type=notifyI'm experiencing a 300sec restart loop when Tor is run as a service. This is Debian stretch using systemd.
This is a system in which tor-0.3.4.8 was installed and running OK. Then I overrode the tor executable with a 0.3.5.4-alpha build...I'm experiencing a 300sec restart loop when Tor is run as a service. This is Debian stretch using systemd.
This is a system in which tor-0.3.4.8 was installed and running OK. Then I overrode the tor executable with a 0.3.5.4-alpha build (with configure `--prefix=`), and it started showing this problem.
I tried some workarounds found on the Net, such as changing the /var/run symlink from /run to ../run (which shouldn't need to be done), tweaking values of ReadWriteDirectories in `tor@default.service`, and changing TimeoutStartSec to 0. None of that worked.
What does work is setting Type=simple instead of notify, but then I came across ticket #11016 and really, notify should work. So if it doesn't, I wonder if this version of tor 0.3.5 alpha could have a fault? How can I look into that more closely to verify?
This is the log in syslog prior to restart:
```
systemd[1]: tor@default.service: Start operation timed out. Terminating.
systemd[1]: Failed to start Anonymizing overlay network for TCP.
systemd[1]: tor@default.service: Unit entered failed state.
systemd[1]: tor@default.service: Failed with result 'timeout'.
systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Anonymizing overlay network for TCP.
systemd[1]: Starting Anonymizing overlay network for TCP...
```
And here is my current `tor@default.service`:
```
[Unit]
Description=Anonymizing overlay network for TCP
After=network.target nss-lookup.target
PartOf=tor.service
ReloadPropagatedFrom=tor.service
[Service]
#Type=notify
Type=simple
NotifyAccess=all
PIDFile=/var/run/tor/tor.pid
PermissionsStartOnly=yes
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor
ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutStartSec=300
TimeoutStopSec=60
Restart=on-failure
LimitNOFILE=65536
# Hardening
AppArmorProfile=-system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH
```
Advice?
**Trac**:
**Username**: jchevaliTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25803Infinite restart loop when daemon crashes2020-06-13T15:38:48ZTracInfinite restart loop when daemon crashesOn Ubuntu, using Tor from the official PPA, when the Tor daemon crashes (im my case because of this bug https://trac.torproject.org/projects/tor/ticket/23693), it is automatically restarted.
As a result Tor uses 100% CPU continuously be...On Ubuntu, using Tor from the official PPA, when the Tor daemon crashes (im my case because of this bug https://trac.torproject.org/projects/tor/ticket/23693), it is automatically restarted.
As a result Tor uses 100% CPU continuously because of its hopeless start->crash->start->crash... behavior.
A better behavior could be to detect the crash (SIGSEV, SIGABRT...) from the process return code and do not restart in that case.
The crash-restart loop behavior can also be dangerous security wise, because for example exploits against ASLR have a framework to do brute force attacks if the process automatically restarts.
I could not understand where this behavior comes from in the code, because the systemd service file in /lib/systemd/system/tor.service seem to be empty.
**Trac**:
**Username**: tiejohg2sahthTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25456tor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernate2020-06-13T15:22:51ZIsis Lovecrufttor's systemd service should SIGHUP tor on resume/thaw after sleep/hibernateI very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that ...I very often need to SIGHUP my tor process after reopening my laptop after the new guard algorithm was merged (I had to also do so before, but now it's seemingly worse), and I hear from other users who are more technically-inclined that there experience is the same. Humans doing things computers can do is bad UX. I propose, at the very least, on *nix systems that we modify the systemd `.service` file(s) we already distribute to do this for the human. (We should also figure out some equivalent for MacOS, Windows, and mobile, if possible, but those can be separate tickets.)
From reading [this question](https://askubuntu.com/questions/661715/make-a-script-start-after-suspend-in-ubuntu-15-04-systemd/661747#661747) that femme linked me to, it looks like the way to do it is either a script which gets installed into `/lib/systemd/system-sleep/`, or a second `.service` file that is wanted by `suspend.target`. I'm not sure which is cleaner? I would assume the `.service` file approach is cleaner, because then it can be selectively enabled/disabled by the human more easily.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25182systemd unit file starts Tor before IPv6 address is available2020-06-13T15:21:46ZSteven Murdochsystemd unit file starts Tor before IPv6 address is availableOn Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address a...On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.
As a work-around I copied `/lib/systemd/system/tor*` to `/etc/systemd/system/` and added `RestartSec=10` to the `[Service]` section of `tor@default.service` and `tor@.service`. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.
See log file below.
```
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24715Job for tor.service failed when /var/run is tmpfs2020-06-13T15:19:23ZTracJob for tor.service failed when /var/run is tmpfsISSUE SUMMARY
=============
For this test I'm running Tor 0.3.2.6-alpha (git-87012d076ef58bb9) on Gentoo Linux. On my system, the /var/run/tor directory does not exist, and /var/run is a link to /run which is mounted as tmpfs:
tmpf...ISSUE SUMMARY
=============
For this test I'm running Tor 0.3.2.6-alpha (git-87012d076ef58bb9) on Gentoo Linux. On my system, the /var/run/tor directory does not exist, and /var/run is a link to /run which is mounted as tmpfs:
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
Attempting to start tor using tor.service fails:
vilhelm@sophia ~ $ sudo systemctl restart tor
Job for tor.service failed because the control process exited with error code.
See "systemctl status tor.service" and "journalctl -xe" for details.
vilhelm@sophia ~ $ sudo systemctl status tor.service
● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-12-06 09:08:19 EST; 4s ago
Process: 12244 ExecStart=/usr/bin/tor -f /etc/tor/torrc (code=exited, status=1/FAILURE)
Process: 12243 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
Main PID: 12244 (code=exited, status=1/FAILURE)
Dec 06 09:08:19 sophia systemd[1]: tor.service: Service hold-off time over, scheduling restart.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Dec 06 09:08:19 sophia systemd[1]: Stopped Anonymizing overlay network for TCP.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Start request repeated too quickly.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
vilhelm@sophia ~ $ sudo journalctl -xe
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has begun starting up.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.596 [notice] Read configuration file "/etc/tor/torrc".
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.597 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:18 sophia tor[12243]: Configuration was valid
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Read configuration file "/etc/tor/torrc".
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Scheduler type KIST has been enabled.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Opening OR listener on 0.0.0.0:443
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Opening Extended OR listener on 127.0.0.1:0
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Extended OR listener listening on port 35193.
Dec 06 09:08:19 sophia Tor[12244]: Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:19 sophia Tor[12244]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:19 sophia Tor[12244]: This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:19 sophia Tor[12244]: Read configuration file "/etc/tor/torrc".
Dec 06 09:08:19 sophia Tor[12244]: Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:19 sophia Tor[12244]: Scheduler type KIST has been enabled.
Dec 06 09:08:19 sophia Tor[12244]: Opening OR listener on 0.0.0.0:443
Dec 06 09:08:19 sophia Tor[12244]: Opening Extended OR listener on 127.0.0.1:0
Dec 06 09:08:19 sophia Tor[12244]: Extended OR listener listening on port 35193.
Dec 06 09:08:19 sophia Tor[12244]: Unable to open "/var/run/tor/tor.pid" for writing: No such file or directory
Dec 06 09:08:19 sophia Tor[12244]: Unable to write PIDFile "/var/run/tor/tor.pid"
Dec 06 09:08:19 sophia Tor[12244]: set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
Dec 06 09:08:19 sophia systemd[1]: tor.service: Main process exited, code=exited, status=1/FAILURE
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has failed.
--
-- The result is RESULT.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Service hold-off time over, scheduling restart.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Dec 06 09:08:19 sophia systemd[1]: Stopped Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has finished shutting down
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has finished shutting down.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Start request repeated too quickly.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has failed.
--
-- The result is RESULT.
SUSPECTED CAUSE
===============
The issue appears to result from the missing /var/run/tor directory and a lack of write permission to create the /var/run/tor/tor.pid PIDFile. I can manually create a /var/run/tor directory, but it will be gone if the system restarts since /var/run is tmpfs. The /var/run/tor directory and appropriate permissions should be configured in the tor.service file by default.
PROPOSED SOLUTION
=================
If I add the following lines to the /lib64/systemd/system/tor.service file the issue is resolved:
Group=tor
RuntimeDirectory=tor
RuntimeDirectoryMode=0770
I suggest adding these lines to the Tor source code contrib/dist/tor.service.in file so that the installed tor.service file will have the configuration lines to automatically create a /var/run/tor directory with the necessary permissions.
**Trac**:
**Username**: vilhelmgrayTor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24577Systemctl tor.service invalid - Tor does not restart on systemctl start tor c...2020-06-13T15:18:41ZTracSystemctl tor.service invalid - Tor does not restart on systemctl start tor commandPlease refer to: https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04/903341
When I looked at tor.service I find it's nothing more than a dummy file that only returns true if the tor.service is...Please refer to: https://askubuntu.com/questions/882527/tor-process-will-not-start-automatically-on-ubuntu-16-04/903341
When I looked at tor.service I find it's nothing more than a dummy file that only returns true if the tor.service is running and not the actual tor program itself:
----
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=Anonymizing overlay network for TCP (multi-instance-master)
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
----
So regardless if the TOR process is actually running or not, tor.service always returns TRUE. This is Invalid. and As a result running: sudo systemctl start|stop tor does nothing as you can see here:
● tor.service - Anonymizing overlay network for TCP (multi-instance-master)
** Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled)**
Active: active (exited) since Sun 2017-12-10 14:24:42 EST; 9min ago
Main PID: 17641 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/tor.service
So for the moment the temporary fix is:
Removing or renaming offending file /lib/systemd/system/tor.service and reloading the scripts w/ systemctl daemon-reload. because the actual and correct script to start tor is in /etc/init.d/tor
After this modifcation the resulting output of sudo systemctl status tor:
● tor.service - LSB: Starts The Onion Router daemon processes
** Loaded: loaded (/etc/init.d/tor; bad; vendor preset: enabled)**
Active: active (exited) since Sun 2017-12-10 14:24:42 EST; 26min ago
Docs: !man:systemd-sysv-generator(8)
Main PID: 17641 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/tor.service
I believe the tor script in /etc/init.d/tor is incorrectly attempting to start/stop tor through tor.service as well.
Please correct this as soon as possible thank you !
**Trac**:
**Username**: d3m0nkingxTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22094Creating private_key/hostname fails with "RO filesystem" message but target d...2020-06-13T15:08:16ZTracCreating private_key/hostname fails with "RO filesystem" message but target dir is actually RWVersion: 0.2.9.10 (git-e28303bcf90b842d) on debian jessie live iso
## Problem
```
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr...Version: 0.2.9.10 (git-e28303bcf90b842d) on debian jessie live iso
## Problem
```
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr 28 10:22:58.000 [err] Couldn't write generated key to "/var/tor/hidden_site/private_key".
```
## Wanted behaviour
These files are to be written in a directory which *IS* writable by the designated running user
These error/warning message seem wrong, and the creating of the hidden service is rendered impossible, if running through systemd
## Steps to reproduce
1) run debian-live-8.7.1-amd64-standard.iso is live mode
2) run following commands
```
gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
cat << "EOF" | sudo tee /etc/apt/sources.list.d/tor.list
deb http://deb.torproject.org/torproject.org jessie main
deb-src http://deb.torproject.org/torproject.org jessie main
EOF
sudo apt-get update
sudo apt-get install deb.torproject.org-keyring
sudo apt-get install tor
sudo systemctl stop tor
sudo mkdir -p /var/tor
sudo mount -t tmpfs tmpfs /var/tor/
sudo mkdir -p /var/tor/hidden_site
sudo chmod 700 /var/tor/hidden_site
sudo chown debian-tor:debian-tor /var/tor/hidden_site
cat << "EOF" | sudo tee /etc/tor/torrc
HiddenServiceDir /var/tor/hidden_site
HiddenServicePort 80 127.0.0.1:8080
EOF
sudo -u debian-tor tor --verify-config
sudo systemctl start tor
```
NOTE: mounting a tmpfs is just an attempt at making sure no RO filesystem was in the game...
3) tor log
```
Apr 28 10:22:58.000 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) opening log file.
Apr 28 10:22:58.067 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 10:22:58.067 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 10:22:58.067 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 10:22:58.067 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 10:22:58.071 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 10:22:58.000 [warn] Couldn't open "/var/tor/hidden_site/private_key.tmp" (/var/tor/hidden_site/private_key) for writing: Read-only file system
Apr 28 10:22:58.000 [err] Couldn't write generated key to "/var/tor/hidden_site/private_key".
Apr 28 10:22:58.000 [warn] Error loading rendezvous service keys
Apr 28 10:22:58.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.9.10 )
```
## Actual mountpoints
```
aufs on / type aufs (rw,noatime,si=2cb2b7e036b24d5d,noxino)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=10240k,nr_inodes=124323,mode=755)
/dev/sr0 on /lib/live/mount/medium type iso9660 (ro,noatime)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,noatime,mode=755)
tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime)
/dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs (ro,noatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=204864k,mode=755)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /var/tor type tmpfs (rw,relatime)
```
## Manual run
If instead of running tor via systemctl, we then launch it manually in shell through ssh :
```
sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
```
`ps auxf` confirms it runs as `debian-tor`.
Here everything goes fine :
```
Apr 28 13:00:41.281 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 13:00:41.281 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 13:00:41.281 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 13:00:41.282 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 13:00:41.286 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 13:00:41.000 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) opening log file.
Apr 28 13:00:41.281 [notice] Tor 0.2.9.10 (git-e28303bcf90b842d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Apr 28 13:00:41.281 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 28 13:00:41.281 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 28 13:00:41.282 [notice] Read configuration file "/etc/tor/torrc".
Apr 28 13:00:41.286 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 28 13:00:41.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Apr 28 13:00:41.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Apr 28 13:00:41.000 [notice] Bootstrapped 0%: Starting
Apr 28 13:00:41.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Apr 28 13:00:42.000 [notice] Opening Socks listener on /var/run/tor/socks
Apr 28 13:00:42.000 [notice] Opening Control listener on /var/run/tor/control
Apr 28 13:00:42.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 28 13:00:42.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 28 13:00:43.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 28 13:00:43.000 [notice] Bootstrapped 100%: Done
```
The hidden service files are created :
```
sudo find /var/tor -ls
31802 0 drwxrwxrwt 3 root root 60 Apr 28 12:30 /var/tor
31841 0 drwx------ 2 debian-tor debian-tor 80 Apr 28 13:00 /var/tor/hidden_site
36795 4 -rw------- 1 debian-tor debian-tor 23 Apr 28 13:00 /var/tor/hidden_site/hostname
36794 4 -rw------- 1 debian-tor debian-tor 887 Apr 28 13:00 /var/tor/hidden_site/private_key
```
**Trac**:
**Username**: nipilTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20930Use new systemd hardening options2020-06-13T15:38:48ZTracUse new systemd hardening optionsUsing systemd 232, I discovered some more hardening options. This is my working systemd unit file.
I'd say the most interesting one is "PrivateUsers" and "PrivateDevices"
Note that I start tor directly as the tor user, listening on ports...Using systemd 232, I discovered some more hardening options. This is my working systemd unit file.
I'd say the most interesting one is "PrivateUsers" and "PrivateDevices"
Note that I start tor directly as the tor user, listening on ports > 1024, because CAP_NET_BIND_SERVICE isn't enough to listen on ports < 1024.
Setting this capability is enough to start dnsmasq as non-root (listening on correct ports), so it is something within tor that breaks.
AFAIK setting these is safe even for older systems since systemd ignores unknown keywords.
```
[Unit]
Description=The Onion Router
After=network-online.target
[Service]
User=tor
Group=tor
ExecStartPre=/usr/bin/tor --verify-config -f /etc/tor/torrc
ExecStart=/usr/bin/tor --RunAsDaemon 0 -f /etc/tor/torrc
ExecReload=/bin/kill -HUP $MAINPID
KillSignal=SIGINT
TimeoutStopSec=32
LimitNOFILE=32768
# Hardening options:
#CapabilityBoundingSet = CAP_NET_BIND_SERVICE
#AmbientCapabilities = CAP_NET_BIND_SERVICE
# Capabilities aren't enough to have ports < 1024
RuntimeDirectory=tor
RuntimeDirectoryMode=0700 # Tor is happy with this default mask
ReadWriteDirectories=/var/lib/tor/
PrivateTmp = yes
PrivateUsers = yes
ProtectKernelTunables = yes
ProtectControlGroups = yes
ProtectKernelModules = yes
PrivateDevices = yes
ProtectHome = yes
ProtectSystem = strict
NoNewPrivileges = yes
[Install]
WantedBy=multi-user.target
```
**Trac**:
**Username**: serafeanTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19762Tor systemd service should have ReadWriteDirectories=/var/run/tor2020-06-13T15:42:16ZTracTor systemd service should have ReadWriteDirectories=/var/run/torTor writes it's pidfile to /var/run/tor/tor.pid by default.
However, https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in specifies that all but 2 directories are read only. Therefore, when one starts tor using:
```
s...Tor writes it's pidfile to /var/run/tor/tor.pid by default.
However, https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in specifies that all but 2 directories are read only. Therefore, when one starts tor using:
```
systemctl start tor
```
using the default configuration, this error is logged in the journal:
```
Jul 26 22:42:32 irrational Tor[19048]: Unable to open "/var/run/tor/tor.pid" for writing: Read-only file system
```
and no pidfile is written.
Adding:
```
ReadWriteDirectories=-/var/run/tor
```
to the [Service] section fixes the problem.
**Trac**:
**Username**: candrewsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19761Tor systemd service should have RuntimeDirectory=tor2020-06-13T15:42:16ZTracTor systemd service should have RuntimeDirectory=torTor writes it's pidfile to /var/run/tor/tor.pid by default. Therefore, the systemd configuration should create this directory with appropriate permissions by default.
In https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.servic...Tor writes it's pidfile to /var/run/tor/tor.pid by default. Therefore, the systemd configuration should create this directory with appropriate permissions by default.
In https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in there should be this line:
{{{
}}}
added to the [Service] section.
See the documentation at https://www.freedesktop.org/software/systemd/man/systemd.exec.html for more detail.
**Trac**:
**Username**: candrewsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19759systemd tor.service hardening: add MemoryDenyWriteExecute=true2020-06-13T15:42:16ZTracsystemd tor.service hardening: add MemoryDenyWriteExecute=trueIn systemd 231, the MemoryDenyWriteExecute option was added:
A new service setting MemoryDenyWriteExecute= has been added, taking
a boolean value. If turned on, a service may no longer create memory
mapping...In systemd 231, the MemoryDenyWriteExecute option was added:
A new service setting MemoryDenyWriteExecute= has been added, taking
a boolean value. If turned on, a service may no longer create memory
mappings that are writable and executable at the same time. This
enhances security for services where this is enabled as it becomes
harder to dynamically write and then execute memory in exploited
service processes. This option has been enabled for all of systemd's
own long-running services.
https://lists.freedesktop.org/archives/systemd-devel/2016-July/037220.html
Can you please add:
```
MemoryDenyWriteExecute=true
```
to https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in in the [Service] section?
Note that systemd < 231 will simply ignore this unknown option so there is no backwards compatibility concern.
**Trac**:
**Username**: candrewsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18356obfs4proxy cannot bind to <1024 port with systemd hardened service unit2020-06-13T14:54:36ZTracobfs4proxy cannot bind to <1024 port with systemd hardened service unitHi,
I was running an obfs4proxy Debian Wheezy bridge with such configuration in torrc:
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443 any more, while tor l...Hi,
I was running an obfs4proxy Debian Wheezy bridge with such configuration in torrc:
```
ServerTransportListenAddr obfs4 0.0.0.0:443
```
When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443 any more, while tor logs had such messages:
```
Feb 21 22:51:09.000 [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied)
Feb 21 22:51:09.000 [warn] Managed proxy at '/usr/bin/obfs4proxy' failed the configuration protocol and will be destroyed.
```
Mind that I have already set the appropriate capability to the obfs4proxy binary:
```
getcap /usr/bin/obfs4proxy
/usr/bin/obfs4proxy = cap_net_bind_service+ep
```
I took some time moving things around and I think the problem resides on the systemd service unit: https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in and specifically the option introduced in b4170421cc58d8c57254f4224ba259e817f48869 .
```
NoNewPrivileges=yes
```
I assume so because flipping 'NoNewPrivileges=no' results in obfs4proxy binding to 443. Also, 'PR_SET_NO_NEW_PRIVS' section in 'man 2 prctl' implies so:
```
PR_SET_NO_NEW_PRIVS (since Linux 3.5)
Set the calling process's no_new_privs bit to the value in arg2. With
no_new_privs set to 1, execve(2) promises not to grant privileges to do
anything that could not have been done without the execve(2) call (for
example, rendering the set-user-ID and set-group-ID permission bits, and
file capabilities non-functional). Once set, this bit cannot be unset.
The setting of this bit is inherited by children created by fork(2) and
clone(2), and preserved across execve(2).
For more information, see the kernel source file Documenta‐
tion/prctl/no_new_privs.txt.
```
I understand that 'NoNewPrivileges=no' is a system security drawback but I also consider a regression to not be able to bind obfs4proxy to ports <1024. Could we find a middle ground?
If that helps, I'm running:
```
tor: 0.2.7.6-1~d80.jessie+1
deb.torproject.org/torproject.org/ jessie/main amd64 Packages
obfs4proxy: 0.0.4-1~tpo1
deb.torproject.org/torproject.org/ obfs4proxy/main amd64 Packages
```
Also:
```
cat /etc/debian_version
8.3
cat /proc/version
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
```
Thanks for your work.
**Trac**:
**Username**: irregulatorTor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/18294systemd AppArmorProfile= directive unavailable leads to not loading AppArmor ...2020-06-13T14:54:14Zadrelanossystemd AppArmorProfile= directive unavailable leads to not loading AppArmor profile on Debian jessieTor version: 0.2.7.6-1~d80.jessie+1
Tor version installed from: deb.torproject.org
`/lib/systemd/system/tor@default.service` uses `AppArmorProfile=system_tor`.
Debian jessie's (currently: Debian stable) version of systemd was compiled ...Tor version: 0.2.7.6-1~d80.jessie+1
Tor version installed from: deb.torproject.org
`/lib/systemd/system/tor@default.service` uses `AppArmorProfile=system_tor`.
Debian jessie's (currently: Debian stable) version of systemd was compiled without AppArmor support.
(The systemd version that is available from Debian stretch (currently: Debian testing) has systemd >= 217 has AppArmor support.)
Source:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760526
Therefore the AppArmor profile will not be load.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16782systemd unit file is not compatible with the AppArmorProfile= directive2020-06-13T14:47:58Zintrigerisystemd unit file is not compatible with the AppArmorProfile= directiveIf I add the `AppArmorProfile=system_tor` directive to the unit file on current Debian sid, tor doesn't start and I get:
`tor.service: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system`
As discussed on the systemd ma...If I add the `AppArmorProfile=system_tor` directive to the unit file on current Debian sid, tor doesn't start and I get:
`tor.service: Failed at step APPARMOR spawning /usr/bin/tor: Read-only file system`
As discussed on the systemd mailing-list last year (http://lists.freedesktop.org/archives/systemd-devel/2014-October/023909.html), setting up AppArmor confinement requires /proc to be writable.
And indeed, adding `ReadWriteDirectories=-/proc` fixes this problem for me. I intend to ask weasel to enable the AppArmor profile back in Debian (which we lost when migrating to systemd), so my question is: do you want `ReadWriteDirectories=-/proc` upstream (as a way to ease the work for downstreams who want to enable AppArmor confinement), or should we add it to the Debian delta?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16398systemd startup timeout on v0.2.6.9 (git-145b2587d1269af4)2020-06-13T14:47:01ZTracsystemd startup timeout on v0.2.6.9 (git-145b2587d1269af4)I'm using experimental builds on Ubuntu 15.04. Since the last update systemd is looping forever in restarting Tor, because it detects a start timeout:
```
Jun 18 12:26:27 dharma systemd[1]: Starting Anonymizing overlay network for TCP.....I'm using experimental builds on Ubuntu 15.04. Since the last update systemd is looping forever in restarting Tor, because it detects a start timeout:
```
Jun 18 12:26:27 dharma systemd[1]: Starting Anonymizing overlay network for TCP...
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:26:27 dharma tor[11487]: Jun 18 12:26:27.321 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:26:27 dharma tor[11487]: Configuration was valid
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.393 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.400 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 18 12:26:27 dharma tor[11490]: Jun 18 12:26:27.400 [notice] Opening Control listener on /var/run/tor/control
Jun 18 12:27:12 dharma systemd[1]: tor.service start operation timed out. Terminating.
Jun 18 12:27:12 dharma systemd[1]: Failed to start Anonymizing overlay network for TCP.
Jun 18 12:27:12 dharma systemd[1]: Unit tor.service entered failed state.
Jun 18 12:27:12 dharma systemd[1]: tor.service failed.
Jun 18 12:27:12 dharma systemd[1]: tor.service holdoff time over, scheduling restart.
Jun 18 12:27:12 dharma systemd[1]: Starting Anonymizing overlay network for TCP...
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:27:12 dharma tor[11572]: Jun 18 12:27:12.796 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:27:12 dharma tor[11572]: Configuration was valid
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.874 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.875 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 18 12:27:12 dharma tor[11575]: Jun 18 12:27:12.882 [notice] Opening Control listener on /var/run/tor/control
```
... and goes on like this forever. This wasn't happening until few days ago, where this last update was distirbuted.
**Trac**:
**Username**: maxxerhttps://gitlab.torproject.org/legacy/trac/-/issues/16162spaces in Tor's systemd unit file causes issues2020-06-13T14:46:28Zproperspaces in Tor's systemd unit file causes issueshttps://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in is currently using spaces.
I recommend not doing this. Causes issues. Info on the issue...
`deb-systemd-helper fails to enable systemd units when using 'WantedBy = ...https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in is currently using spaces.
I recommend not doing this. Causes issues. Info on the issue...
`deb-systemd-helper fails to enable systemd units when using 'WantedBy = ' with spaces`:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786418
More reasoning why this is syntactically incorrect:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786421Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14141enhancments and fixes for systemd support2020-06-13T14:41:38ZTracenhancments and fixes for systemd supportThe following patch series contains:
1) fix unit & code to work with both RunAsDaemon = 0 or 1
2) improve information about state presented to administrator
3) fix and enable watchdog support
Detailed descriptions inside each patch.
...The following patch series contains:
1) fix unit & code to work with both RunAsDaemon = 0 or 1
2) improve information about state presented to administrator
3) fix and enable watchdog support
Detailed descriptions inside each patch.
**Trac**:
**Username**: tomek@pipebreaker.plTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13805Improve hardening in tor.service2020-06-13T14:44:34ZTracImprove hardening in tor.serviceI suggest that tor.service's hardening implementation be changed. These lines would be replaced:
```
[Service]
DeviceAllow = /dev/null rw
DeviceAllow = /dev/urandom r
InaccessibleDirectories = /home
ReadOnlyDirectories = /
ReadWriteDirec...I suggest that tor.service's hardening implementation be changed. These lines would be replaced:
```
[Service]
DeviceAllow = /dev/null rw
DeviceAllow = /dev/urandom r
InaccessibleDirectories = /home
ReadOnlyDirectories = /
ReadWriteDirectories = /var/lib/tor
ReadWriteDirectories = /var/log/tor
ReadWriteDirectories = /var/run/tor
ReadWriteDirectories = /proc
```
With these lines:
```
PrivateDevices = yes
ProtectHome = yes
ProtectSystem = full
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID
```
Using PrivateDevices instead of DeviceAllow's is more secure as it create a totally separate /dev as well as removing the CAP_MKNOD capability.
ProtectHome makes /home inaccessible, equivalent to "InaccessibleDirectories = /home" but (arguably) more comprehensible.
ProtectSystem=full make /usr and /etc read only.
CapabilityBoundingSet reduces the process capability to just what it needs.
See http://www.freedesktop.org/software/systemd/man/systemd.exec.html
This discussion was started at https://bugs.gentoo.org/show_bug.cgi?id=529212 and the suggestion to use the higher level constructs was made by the Gentoo systemd team.
For historical reference, tor.service was added in #8368
**Trac**:
**Username**: candrewsTor: 0.2.6.x-final