Tor not running on debian-10 template with security-misc 3:7.7-1 installed

[minimal]

Hello!
As per the title, Tor is not running anymore on a debian-10 template with security-misc 3:7.7-1 installed from Whonix’s buster-proposed-updates repo. This is the output of my syslog when I restart Tor daemon.

localhost Tor[789]: Directory /run/tor cannot be read: Permission denied
localhost Tor[789]: Before Tor can create a control socket in “/run/tor/control”, the directory “/run/tor” needs to exist, and to be accessible only by the user and group account that is running Tor.

I am running another version of security-misc (3:3.5-1) on another debian-10 template which I use for sys-corridor and I am not experiencing any problem there. Also, everything is working well on Whoinx templates.

Could somebody give me a suggestion in order to fix this problem, please?
Cheers.

[awokd]

Have you tried to rollback to security-misc 3:3.5-1?

[minimal]

Hi and thanks for your answer.
Yes, I have just tried and Tor is not working. Here are my logs:

$ tail -f /var/log/syslog
localhost Tor[776]: Directory /run/tor cannot be read: Permission denied
localhost Tor[776]: Before Tor can create a control socket in “/run/tor/control”, the directory “/run/tor” needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix systems, anybody who can list a socket can connect to it, so Tor is being careful.
localhost Tor[776]: New control connection opened from 127.0.0.1.

and

$ tail -f /var/log/vanguards
NOTICE: Vanguards 0.3.1 connected to Tor 0.4.1.5 using stem 1.7.1
NOTICE: Tor needs descriptors: Cannot read /var/lib/tor/cached-microdesc-consensus: [Errno 2] No such file or directory: ‘/var/lib/tor/cached-microdesc-consensus’. Trying again…

I don’t think this is relevant but if I

sudo su
/usr/lib/security-misc/permission-lockdown failed: exit code 2

And I become root.

Thanks.

[awokd]

I wonder if there’s an undefined dependency on something specific to
Whonix templates. “Bruce force” way to fix it is to uninstall the broken
debian-10 template, and reinstall a new one.

[minimal]

Hi awokd,
yes if no solution comes up I will be forced to uninstall the broken debian-10-template and completely reconfigure (gosh) a new one.

[Patrick]

@minimal

localhost Tor[776]: Directory /run/tor cannot be read: Permission denied

Try this:

Tor Documentation for Whonix Users

@minimal

/usr/lib/security-misc/permission-lockdown failed: exit code 2

Please create a separate thread for that.

[minimal]

Thanks for your answer and apologies for the late reply.

I updated again security-misc to the last version on the buster-proposed-repo (3:8.2-1) Then I have chowned the dir and restarted Tor as suggested in the link you posted above. Tor is still not working, but the output has changed a bit.

tail-f /var/log/syslog
localhost Tor[783]: Directory /run/tor cannot be read: Permission denied
localhost Tor[783]: Before Tor can create a control socket in “/run/tor/control”, the directory “/run/tor” needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix systems, anybody who can list a socket can connect to it, so Tor is being careful.)
localhost Tor[783]: New control connection opened from 127.0.0.1

and

tail -f /var/log/vanguards
NOTICE: Tor needs descriptors: Cannot read /var/lib/tor/cached-microdesc-consensus: [Errno 2] No such file or directory: ‘/var/lib/tor/cached-microdesc-consensus’. Trying again…

Indeed, the file is not present.

If I

sudo touch /var/lib/tor/cached-microdesc-consensus && sudo chown debian-tor:debian-tor /var/lib/tor/cached-microdesc-consensus

then

tail -f /var/log/vanguards.lorg
NOTICE: Tor needs descriptors: Descriptor information is unavailable, tor might still be downloading it. Trying again…

and

tail-f /var/log/syslog
localhost Tor[783]: Directory /run/tor cannot be read: Permission denied
localhost Tor[783]: Before Tor can create a control socket in “/run/tor/control”, the directory “/run/tor” needs to exist, and to be accessible only by the user and group account that is running Tor. (On some Unix systems, anybody who can list a socket can connect to it, so Tor is being careful.)
localhost Tor[783]: New control connection opened from 127.0.0.1.
localhost Tor[783]: Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (Connection timed out; TIMEOUT; count 22; recommendation warn; host XXXXXXXXXXXXXXXXX at YYYYYYY:443)
localhost Tor[783]: 21 connections have failed:
localhost Tor[783]: 21 connections died in state connect()ing with SSL state (No SSL object)

Cheers

[Patrick]

@minimal

localhost Tor[783]: Directory /run/tor cannot be read: Permission denied

Check permissions using the following two commands. Then post output here.

Run:

sudo ls -la /run/ | grep tor

Expected output:

drwxr-sr-x 2 debian-tor debian-tor 140 Sep 9 08:22 tor

Run:

sudo ls -la /run/tor

Expected output:

total 88
drwxr-sr-x 2 debian-tor debian-tor 140 Sep 9 08:22 .
drwxr-xr-x 31 root root 780 Sep 9 08:22 …
srw-rw---- 1 debian-tor debian-tor 0 Sep 9 08:22 control
-rw-r----- 1 debian-tor debian-tor 32 Sep 9 08:22 control.authcookie
-rw-r----- 1 debian-tor debian-tor 78493 Sep 9 08:20 log
srw-rw-rw- 1 debian-tor debian-tor 0 Sep 9 08:22 socks
-rw-r–r-- 1 debian-tor debian-tor 4 Sep 9 08:22 tor.pid

Also how did you install Tor?

sudo apt install tor

Whonix uses Tor from buster repository from deb.torproject.org, not from packages.debian.org. Downoaded from there and uploaded to deb.whonix.org. (Tor integration in Whonix Development Notes) That might make a difference.

security-misc package isn’t tested with Tor from packages.debian.org. Only with deb.torproject.org. But by using deb.whonix.org, you’d also get the same Tor version.

(See also: GitHub - Kicksecure/anon-shared-build-apt-sources-tpo: Adds The Tor Projects's (TPO) APT repository to Derivative Linux Distributions during build. - Useful, because TPO's repository sometimes contains better/more recent versions of Tor, obfsproxy, torsocks, etc. This package is produced independently of, and carries no guarantee from, The Tor Project. might be convenient.)

[minimal]

Hi, thanks for your answer.
Here are my outputs:

sudo ls -la /run/ | grep tor

Output:

drwxr-sr-x 2 debian-tor debian-tor 100 Sep X XX:XX to

And

sudo ls -la /run/tor/

Output:

total 8
drwxr-sr-x 2 debian-tor debian-tor 100 Sep X XX:XX .
drwxr-xr-x 27 root root 740 Sep X XX:XX …
-rw-r----- 1 debian-tor debian-tor 32 Sep X XX:XX control.authcookie
srw-rw-rw- 1 debian-tor debian-tor 0 Sep X XX:XX socks
-rw-r–r-- 1 debian-tor debian-tor 4 Sep X XX:XX tor.pid

That’s it.

I am using deb.torproject.org repos. As I specified in my first post, I am experiencing this problem only in a debian-10 template with security-misc installed. Whonix-ws or whonix-gw templates are not affected by such issue.

[Patrick]

Works for me in debian-10 TemplateVM.

---

dpkg -l | grep security-misc

ii security-misc 3:8.2-1 all enhances misc security settings

---

ii tor 0.4.1.5-1~d10.buster+1 amd64 anonymizing overlay network for TCP

---

I am not familiar with vanguards.

vanguards - Additional protections for Tor Onion Services

https://packages.debian.org/buster/vanguards vanguards vanguards uses the Stem Tor control port library to connect to a Tor control port. It has three defense subsystems: Vanguards, Rendguard, and Bandguards. All three subsystems apply to both service-side and client-side onion service activity, but NOT to any client traffic that exits the Tor network to the normal Internet.

The mix with it may be the cause. However, even that works for me.

sudo systemctl status vanguards
● vanguards.service - Additional protections for Tor onion services
   Loaded: loaded (/lib/systemd/system/vanguards.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-09-09 08:28:08 EDT; 20s ago
     Docs: man:vanguards(1)
 Main PID: 4485 (vanguards)
    Tasks: 3 (limit: 4667)
   Memory: 84.7M
   CGroup: /system.slice/vanguards.service
           └─4485 /usr/bin/pypy /usr/bin/vanguards

Sep 09 08:28:08 atest-debian-10-based systemd[1]: vanguards.service: Main process exited, code=killed, status=15/TERM
Sep 09 08:28:08 atest-debian-10-based systemd[1]: vanguards.service: Succeeded.
Sep 09 08:28:08 atest-debian-10-based systemd[1]: Stopped Additional protections for Tor onion services.
Sep 09 08:28:08 atest-debian-10-based systemd[1]: Started Additional protections for Tor onion services.
Sep 09 08:28:08 atest-debian-10-based vanguards[4485]: NOTICE[Mon Sep 09 08:28:08 2019]: Creating new vanguard state file at: /var/lib/tor/vanguards.state
Sep 09 08:28:08 atest-debian-10-based vanguards[4485]: NOTICE[Mon Sep 09 08:28:08 2019]: Vanguards 0.3.0 connected to Tor 0.4.1.5 using stem 1.7.1

[Patrick]

Also managed to sudo apt purge tor and reinstall of Tor while security-misc was installed.

[minimal]

It is kind of weird but finally I managed to make Tor working on the debian-10 template with security-misc installed. What I did?

apt purge tor vanguards

Then I reinstalled everything. Magic, it worked! So I changed again my torrc and added the two options that I have been used for ages:

Sandbox 1
ConnectionPadding 1

I restarted Tor and Vanguards. Nothing was working again and when I run

sudo -u debian-tor nyx

the output was:

Unable to connect to tor. Maybe it’s running without a ControlPort?

Initially I have tried to change vanguards.conf as follow:

#control_ip = 127.0.0.1
#control_port = 9051
control_socket = /var/run/tor/control

But nothing was working. Then I just commented out

#Sandbox 1

And everything is working fine again. Not sure why.

I have been using this option with vanguards for months, even before the Debian Buster release. I honestly have no idea if the culprit of this is related to Tor 4.1, security-misc 3:7 or what else. However, it SEEMS that now everything is working again.