0

[Archlinux 5.9.8-arch1-1]

Since my kernel update 5.8.5 -> 5.9.3, tor.service fails at boot. The corresponding client setup is pretty plain but I can't find the hold-up ...

$ tor --version
Tor version 0.4.4.5.
$ systemctl is-enabled tor.service
enabled
$ systemctl status tor.service
● tor.service - Anonymizing overlay network for TCP
    Loaded: loaded (/usr/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
    Active: failed (Result: exit-code) since Sat 2020-11-14 15:23:38 CET; 9min ago
  Process: 1212 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
  Process: 1219 ExecStart=/usr/bin/tor -f /etc/tor/torrc (code=exited, status=1/FAILURE)
 Main PID: 1219 (code=exited, status=1/FAILURE)

Nov 14 15:23:38 rameau systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Nov 14 15:23:38 rameau systemd[1]: Stopped Anonymizing overlay network for TCP.
Nov 14 15:23:38 rameau systemd[1]: tor.service: Start request repeated too quickly.
Nov 14 15:23:38 rameau systemd[1]: tor.service: Failed with result 'exit-code'.
Nov 14 15:23:38 rameau systemd[1]: Failed to start Anonymizing overlay network for TCP.

... and what seems to be the significant extract from my journal log at boot:

$ systemctl -b -e
Nov 14 15:59:02 HOST audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 15:59:02 HOST audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 15:59:02 HOST systemd[1]: Starting Anonymizing overlay network for TCP...
Nov 14 15:59:02 rameau tor[9339]: Nov 14 15:59:02.237 [notice] Tor 0.4.4.5 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1h, Zlib 1.2.11, Liblzma 5.2.5, and Libzstd 1.4.5.
Nov 14 15:59:02 HOST tor[9339]: Nov 14 15:59:02.237 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 14 15:59:02 HOST tor[9339]: Nov 14 15:59:02.237 [notice] Read configuration file "/etc/tor/torrc".
Nov 14 15:59:02 HOST tor[9339]: Configuration was valid
Nov 14 15:59:02 HOST systemd[1]: Started Anonymizing overlay network for TCP.
Nov 14 15:59:02 HOST audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.259 [notice] Tor 0.4.4.5 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1h, Zlib 1.2.11, Liblzma 5.2.5, and Libzstd 1.4.5.
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.259 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.259 [notice] Read configuration file "/etc/tor/torrc".
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.262 [warn] You appear to lack permissions to change memory limits. Are you root?
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.262 [warn] Unable to raise RLIMIT_MEMLOCK: Operation not permitted
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.262 [notice] Unable to lock all current and future memory pages: Cannot allocate memory
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.262 [warn] Failed to parse/validate config: DisableAllSwap failure. Do you have proper permissions?
Nov 14 15:59:02 HOST tor[9340]: Nov 14 15:59:02.262 [err] Reading config failed--see warnings above.
Nov 14 15:59:02 HOST systemd[1]: tor.service: Main process exited, code=exited, status=1/FAILURE
Nov 14 15:59:02 HOST systemd[1]: tor.service: Failed with result 'exit-code'.
Nov 14 15:59:02 HOST audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Nov 14 15:59:02 HOST systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Nov 14 15:59:02 HOST systemd[1]: Stopped Anonymizing overlay network for TCP.
Nov 14 15:59:02 HOST audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 15:59:02 HOST audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 14 15:59:02 HOST systemd[1]: tor.service: Start request repeated too quickly.
Nov 14 15:59:02 HOST systemd[1]: tor.service: Failed with result 'exit-code'.
Nov 14 15:59:02 HOST systemd[1]: Failed to start Anonymizing overlay network for TCP.

Before everything worked well for my couple of client-apps using system proxy 127.0.0.1 and default config localhost port bind on 9050: namely Firefox v82.0.3 and a chat-client.

Here is what I have configured:

$ cat /etc/tor/torrc | sed -n '/^[^#]/p'
SOCKSPort 9050      # Default
TestSocks 1
SocksPolicy accept 192.168.0.0/16
Log notice file /var/log/tor/notices.log
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword 16:............................................
CookieAuthentication 1   # New
CookieAuthFile /var/lib/tor/control_auth_cookie  # New
CookieAuthFileGroupReadable 1   # New
DataDirectoryGroupReadable 1    # New
DisableAllSwap 1     # New
User tor             # New   
ExitNodes {dk},{..},....   # list includes 9 countries in total

The "# New comments above indicate the new setting I tries when troubleshooting. They were not part of the setup initially, i.e. prior to my kernel update, when everything worked fine.

$ cat /usr/lib/systemd/system/tor.service
[Unit]
Description=Anonymizing overlay network for TCP
After=syslog.target network.target nss-lookup.target

[Service]
NotifyAccess=all
ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config
ExecStart=/usr/bin/tor -f /etc/tor/torrc
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutSec=60
Restart=on-failure
WatchdogSec=1m
LimitNOFILE=32768
User=root
Group=root
#Type=notify
Type=simple

# Hardening
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH

[Install]
WantedBy=multi-user.target

and the various permission and ownership for various files are:

$ ls -lAF /var/lib | grep tor
drwxr-x---  3 tor     tor      4096 20201114-155218 tor/
$ ls -lAF /var/lib/* | grep -e "tor[ :] "
/var/lib/tor:
   20 -rw-r----- 1 tor tor    20442 20201030-165058 cached-certs
 2236 -rw------- 1 tor tor  2286299 20201114-155145 cached-microdesc-consensus
10416 -rw-r----- 1 tor tor 10662998 20201102-152622 cached-microdescs
 2664 -rw-r----- 1 tor tor  2724664 20201114-155146 cached-microdescs.new
    4 drwx------ 2 tor tor     4096 20180524-182000 keys/
    0 -rw------- 1 tor tor        0 20201114-155143 lock
   20 -rw------- 1 tor tor    18004 20201114-155218 state

Finally I made sure that I had the proper user added to the tor group:

$ sudo usermod -a -G tor myuser
$ newgrp tor
$ cat /etc/group | grep "tor:"
tor:x:43:myuser
# sudo systemctl daemon-reload
# sudo systemctl restart tor.service
$ systemctl status tor.service
...   ***same as before, no change***

I don't grok the journal log bit about not being allowed to modify memory limits and have not found any doc on that. I strongly suspect the previous line, Unable to raise RLIMIT_MEMLOCK, is the key. It would be consistent with a CAPABILITY issue. How could that even happen, I am not sure, but it looks like something got broken along my merry way when updating my kernel ...

Could somebody give me an opinion ?

Improve this question
5
  • The Unable to raise RLIMIT_MEMLOCK error should only appear if you've set DisableAllSwap in your torrc, which requires you to start tor as root. Try removing that option and update your post with the new log messages if they change.
    – Steve
    Commented Nov 14, 2020 at 19:59
  • Yes, @Steve and thank you for helping. I new that and wanted DisableAllSwap 1 (defaults to 0) so memory would not be paged out (no "swapping") but would remain within the limits imposed by hardware and other process requirements. For me this was an experiment in trying to harden the box with that setup. The idea was to boot with User=root and Group=root and then reduce privileges to User tor in /etc/tor/torrc. This actually works if you add CAP_SYS_RESOURCE in your CapabilityBoundingSet in the tor-service unit file. I have not had the time to investigate that fully just yet.
    – Cbhihe
    Commented Nov 15, 2020 at 10:56
  • ... and to address your request, without any line tagged # New in the /etc/tor/torrc file above and with no User=root \n Group=root in the unit file, this is just reverting to the original setup, which just does not fly; hence my post. If I do add the capability per my comment above, it works as before.
    – Cbhihe
    Commented Nov 15, 2020 at 10:57
  • Your post didn't say anything about hardening, just that you upgraded your kernel version and it broke tor, and that you added new torrc options to try to fix it.
    – Steve
    Commented Nov 15, 2020 at 18:55
  • @steve: [on DIsableAllSwap] You are right, I did not use the word (hardening) in the intervening explanations in the post, because I thought it hardly mattered. But the flag was always there and tagged # New. As it turns out it was in fact inconsequential. (I was effectively starting the service as User=root then switching to user tor.) Also I had tried both setups, with and without ... with the same result. The solution lies in attributing the right capabilities to the non-privileged process, be it from the start or later on if the process is owned by rootwhen execution starts.
    – Cbhihe
    Commented Nov 15, 2020 at 19:57

1 Answer 1

Reset to default
1

The tor.service is normally run as a non-privileged process (i.e. the process' owner's UID is not 0). This is true unless (as is the case here) the flag DisableAllSwap is set to 1 (default is 0) in which case the process must be started as root (see service unit file) and later passed on to user tor (see file etc/tor/torrc).

No matter, for both configurations the service will start and remain active, provided you add CAP_SYS_RESOURCE to your CapabilityBoundingSet flag in unit file: /usr/lib/systemd/system/tor.service. This is the requirement for the tor.service process owned by user tor to be able to negotiate the memory resources it needs.

CapabilityBoundingSet=CAP_SYS_RESOURCE CAP_SETUID CAP_SETGID
CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH

CapabilityBoundingSet controls which capabilities to include for the executed process. Adding CAP_SYS_RESOURCE allows the non-privileged process to increase ressource limits (see setrlimit(2)). For more info, see the capabilities(7) manpage.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .