Torrc, unit files, confusion

Support Relay Operator
1

Hello together,

I’ve gotten myself stuck in a situation that I can’t get out of. The following:

I have a working relay. You can find the config for it in the attachment [1].

I want to move parts of the config. So I use %include.
I don’t do anything else than moving parts of the working config to other files. There are no changes at all. But, tor does not start anymore.In the attachment [2] you can find the config with %include. The folder structure is the following:

├── info.html
├── rc.d
│   ├── contact.rc
│   ├── family.rc
│   └── nickname.rc
├── torrc
└── torsocks.conf

No matter what I do, I can’t get it to enable debug logs when I start tor from the unit file. This is unchanged, but I attached it anyway [3].

Anyway, I start tor as root, then everything works [4]. I have no idea where something should be wrong with the permissions. I have also recursively set the permission of /etc/tor/ to the user debian-tor, but it doesn’t help.

When I do the following:

cat rc.d/* >> torrc && sed -i /include/d torrc && systemctl restart tor

Everything works fine again.

My system:
Linux privacy 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux
Tor version 0.4.6.9.
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.33 as libc.
Tor compiled with GCC version 10.2.1

Maybe I’m still too tired to figure it out. But please, can someone give me some advice where to look further? Or at least tell me how to get a debug log when I start tor from the systemd-unit. Then I would surely get further.

Thanks for your attention and help.
Martin

[1]

SocksPort 0
RunAsDaemon 1

ORPort 9001
ORPort [::]:9001

ContactInfo abuse(at)linkspartei(dot)org url:linkspartei.org proof:uri-rsa ciissversion:2 btc:bc1qnskznvxkq63yuqcvp3ppc37hp364n2f08lv46v
MyFamily C2CD35F0766CAE4184F75299186FE8CF1A131E61,58AC93FB66FE2A14A4A7D35C05E6BE41A6C7046B,EDB480C34207BC3D38CD903F475CD4A85659F810,FDAA4F76F778215F02B0B02DCE8E8504179BCDC6,6A0A9C3B3381C89CCB85C64BBCF6942805AA477B,171E93EA1DF7524A87ED272CCE8CF83BCD9BF1BC,F072C8FDA61719777AA3BAB2CDADE416763749F8,4CF97826972A7FDD895B0D020FE56341ED5E5F90,16688DB4CD7B17E2846E9BE90DFCE89456DAE5CB,845BA84EDBC85AD3B1D504089BAE698E9360DCBF,2F9EAEB446302E4A4B6451AC2A8DAB9128FDA7D7,FDE290ACE9C213BE9F7BB7FB288DD9767B6ABB31
Nickname lokit09

Log notice file /var/log/tor/notices.log

DirPort 80
DirPortFrontPage /etc/tor/info.html

ExitRelay 1
IPv6Exit 1
DisableDebuggerAttachment 0
ControlPort 9051
CookieAuthentication 1

[2]

SocksPort 0
RunAsDaemon 1

ORPort 9001
ORPort [::]:9001

%include /etc/tor/rc.d

Log notice file /var/log/tor/notices.log

DirPort 80
DirPortFrontPage /etc/tor/info.html

ExitRelay 1
IPv6Exit 1
DisableDebuggerAttachment 0
ControlPort 9051
CookieAuthentication 1

[3]

# /lib/systemd/system/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
NotifyAccess=all
PIDFile=/run/tor/tor.pid
PermissionsStartOnly=yes
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /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=-/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH

[4]

Feb 16 07:40:17.650 [notice] Tor 0.4.6.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Feb 16 07:40:17.650 [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 16 07:40:17.650 [notice] Read configuration file "/etc/tor/torrc".
Feb 16 07:40:17.651 [notice] Processing configuration path "/etc/tor/rc.d" at recursion level 1.
Feb 16 07:40:17.651 [notice] Including configuration file "/etc/tor/rc.d/contact.rc".
Feb 16 07:40:17.651 [notice] Including configuration file "/etc/tor/rc.d/family.rc".
Feb 16 07:40:17.651 [notice] Including configuration file "/etc/tor/rc.d/nickname.rc".
Feb 16 07:40:17.651 [warn] Configuration port ORPort 9001 superseded by ORPort [::]:9001
Feb 16 07:40:17.651 [notice] Based on detected system memory, MaxMemInQueues is set to 732 MB. You can override this by setting MaxMemInQueues by hand.
Feb 16 07:40:17.653 [warn] Configuration port ORPort 9001 superseded by ORPort [::]:9001
Feb 16 07:40:17.653 [notice] Opening Control listener on 127.0.0.1:9051
Feb 16 07:40:17.653 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
Feb 16 07:40:17.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 16 07:40:17.653 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001
Feb 16 07:40:17.653 [notice] Opening OR listener on [::]:9001
Feb 16 07:40:17.653 [notice] Opened OR listener connection (ready) on [::]:9001
Feb 16 07:40:17.653 [notice] Opening Directory listener on 0.0.0.0:80
2

If u want the debug log written to a file use Log debug file /path/to/file and make sure debian-tor has write access to that file. To get the debug logs in your journal use Log debug syslog. Afterwards you can see them with journalctl -u tor@default.

3

Hey @jarl

neither in syslog nor in the file anything is logged.

Log debug file /etc/tor/log

ls -l log 
-rw-r--r-- 1 debian-tor debian-tor 0 Feb 17 22:26 log
4

Try to use /var/log/tor/debug.log as logfile. /etc/tor might be blocked for writes because of the system hardening in systemd.

5

Just to be sure I reinstalled the debian, installed tor from the tor-repo and it is exactly the same behavior.

6

Thanks, but that doesn’t work either. With the specification syslog it should have ended up in the journal. Not even there something arrives.

[22:54:53] root@09.gdn.exit.tor.loki.tel:/etc/tor touch /var/log/tor/debug.log 
[22:55:09] root@09.gdn.exit.tor.loki.tel:/etc/tor chown -R debian-tor:debian-tor /var/log/tor
[22:55:14] root@09.gdn.exit.tor.loki.tel:/etc/tor l /var/log/tor/
total 8.0K
drwxr-s---  2 debian-tor debian-tor 4.0K Feb 17 22:54 ./
drwxr-xr-x 11 root       root       4.0K Feb 17 22:44 ../
-rw-r--r--  1 debian-tor debian-tor    0 Feb 17 22:54 debug.log
[22:55:19] root@09.gdn.exit.tor.loki.tel:/etc/tor systemctl restart tor
[22:55:24] root@09.gdn.exit.tor.loki.tel:/etc/tor cat /var/log/tor/debug.log

As soon as I use %include in the torrc, everything fails. If I add the 3 lines that are in the rc.d folder back into the torrc and remove the %include, everything runs without problems.

I also can’t see that I’m misunderstanding the %include function. Because as seen in my first post, the files are loaded - but only when I run tor as root.

I have the line Log debug.. also above the line %include in the torrc to make sure that it is read even if the config fails at %include.

Ok, so lets verify config:

[23:09:48] root@09.gdn.exit.tor.loki.tel:/etc/tor runuser -l debian-tor -c 'tor --verify-config'
Feb 17 23:09:50.346 [notice] Tor 0.4.6.9 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Feb 17 23:09:50.346 [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 17 23:09:50.346 [notice] Read configuration file "/etc/tor/torrc".
Feb 17 23:09:50.346 [notice] Processing configuration path "/etc/tor/rc.d" at recursion level 1.
Feb 17 23:09:50.346 [notice] Including configuration file "/etc/tor/rc.d/contact.rc".
Feb 17 23:09:50.347 [notice] Including configuration file "/etc/tor/rc.d/family.rc".
Feb 17 23:09:50.347 [notice] Including configuration file "/etc/tor/rc.d/nickname.rc".
Feb 17 23:09:50.347 [warn] Configuration port ORPort 9001 superseded by ORPort [::]:9001
Feb 17 23:09:50.347 [notice] Based on detected system memory, MaxMemInQueues is set to 732 MB. You can override this by setting MaxMemInQueues by hand.
Feb 17 23:09:50.348 [notice] Not disabling debugger attaching for unprivileged users.
Configuration was valid
7

I just tried to replicate your setup and ran into the same problem. Debug logs couldn’t be activated, since tor wasn’t even able to apply the configuration. Im pretty sure it has to do with the system hardening. If you comment the line AppArmorProfile=-system_tor in /lib/systemd/system/tor@default.service everything works as expected.

8

Apparmor stops tor from reading those files. It works if you add the line owner /etc/tor/** r, into /etc/apparmor.d/system_tor. Im not an expert on apparmor so don’t ask me if this has some big safety implications, but from my understanding this should only give the user debian-tor read-access to /etc/tor/ and all its subdirectories.

1 Like
9

Wonderful, that’s how it works.
Now apparmor is a kind of black box for me. I can’t make sense of the profile and where exactly the correlation is.

[23:23:10] root@09.gdn.exit.tor.loki.tel:/etc/tor cat !:1
cat /etc/apparmor.d/system_tor
# vim:syntax=apparmor
#include <tunables/global>

profile system_tor flags=(attach_disconnected) {
  #include <abstractions/tor>

  owner /var/lib/tor/** rwk,
  owner /var/lib/tor/ r,
  owner /var/log/tor/* w,

  # During startup, tor (as root) tries to open various things such as
  # directories via check_private_dir().  Let it.
  /var/lib/tor/** r,

  /{,var/}run/tor/ r,
  /{,var/}run/tor/control w,
  /{,var/}run/tor/socks w,
  /{,var/}run/tor/tor.pid w,
  /{,var/}run/tor/control.authcookie w,
  /{,var/}run/tor/control.authcookie.tmp rw,
  /{,var/}run/systemd/notify w,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/system_tor>
}
10

Thank you! That comes as a solution for me for now.
I will open a bug that there is a conflict here between AppArmor and the function of recursive include.

Hey man, you’ve been a huge help. Now I can sleep peacefully again :slight_smile:

11

This topic was automatically closed 2 hours after the last reply. New replies are no longer allowed.