It's currently documented for Qubes-Whonix, but not for KVM.
https://www.whonix.org/wiki/Corridor
It would be good as sanity test that Whonix is leak free today and stays leak free as Whonix developers (future firewall changes T509, IPv6, etc.)
Either as a separate wiki page. Then we could transform many shared contents into wiki templates and re-use them on both pages.
Or on the same wiki page. Then we would work with expand buttons where Qubes, VirtualBox and KVM instructions differ.
Overview of instructions relevant to KVM (feel free to correct me):
When this is tested more it would be great to have by default.
HulaHoop (HulaHoop):
HulaHoop added a comment.
Overview of instructions relevant to KVM (feel free to correct me): - BridgeFirewall instructions and its .d config path
Yes.
- Should we assume the Whonix repo is enabled and just refer to the already documented steps on enabling it if the user hasn't done this?
Since these instructions assume Debian, not Whonix, we cannot assume the
Whonix repo is enabled.
- Is the warning about giving away that someone is a Whonix user valid here?
I did not write that. Connecting to whonix.org repository would give
away Whonix, most likely.
It is in context of
https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP which is
very specific. Would assume someone managed to hide Whonix [and Tor] to
this point by not ideally never visiting Whonix website without Tor
Browser or at least never downloading from whonix.org. Ideally also
hiding Tor. Not sure this is a realistic model at all.
Does this affect non-Qubes Whonix?
No difference between Qubes-Whonix / Non-Qubes-Whonix.
- testing/logging/results
Yes.
When this is tested more it would be great to have by default.
How? Shipping 3 VMs rather than 2 by default?
(This cannot be merged into Whonix-Gateway. It is either,
I think in case of Non-Qubes-Whonix, installing corridor in a VM is not that useful. More useful:
This cannot be merged into Whonix-Gateway
Oh OK. I hadn't seen this before posting this question on the forum.
I think in case of Non-Qubes-Whonix, installing corridor in a VM is not that useful. More useful:
+1
corridor as a host firewall
Yes. Maybe make it a dependency of usability (or security-misc)? So its a part of the Whonix host security improvements initiative.
First of all, this very ticket needs to be implemented.
usability-misc dependency, no, since very much out of scope.
security-misc dependency, no, since that would make a non-Tor specific package suddenly result in shipping a firewall that breaks networking for all but Tor connections.
It could be a dependency of a Whonix host package. Perhaps there would be two Whonix host packages. One that permits clearnet traffic and one that does not. Or someone have this configureable. It is speculative, since currently there is no whonix-host package and no Whonix host maintainer. [Besides Qubes OS functioning as a Whonix host.]
I'm thinking about how to make this available for KVM users first so it can be run and tested. Then documented to complete this ticket.
security-misc dependency, no, since that would make a non-Tor specific package suddenly result in shipping a firewall that breaks networking for all but Tor connections.
HulaHoop (HulaHoop):
- The Whonix-Host package doesn't exist and won't for a long time. I don't see the need for it yet.
I guess it would be useful. Depending on security-misc, providing a
firewall, perhaps allowing/blocking clearnet traffic.
( blocking would be useful to implement:
https://www.whonix.org/wiki/DoNot#Do_not_use_clearnet_and_Tor_at_the_same_time.
)
Perhaps also install sdwdate.
> security-misc dependency, no, since that would make a non-Tor specific package suddenly result in shipping a firewall that breaks networking for all but Tor connections. - What if its not enabled by default. Just merely installed for the user to enable at will?
That is not how Debian packages are usually made. Once you install them,
they start providing their functionality. Servers automatically start etc.
The corridor package at the moment works like that. Now, the
security-misc package could have a "feature" to disable the corridor
systemd target by default. Such a "feature" sounds like a bug.
Imagine someone using corridor and then installing security-misc, just
wondering it just broke corridor.
I don't think a dependency would be right or useful. The corridor
package could be manually installed on its own. And if it should be part
of some kind of meta package, it would be a lot better to create a new
packages such as whonix-host or anon-host-enhancements or something like
that.
Such a anon-host-enhancements package or so could depend on both,
security-misc and corridor. That would be a sane and robust solution.
I'm thinking about how to make this available for KVM users first so
it can be run and tested.
Just install corridor on the host and configure it as a host firewall
(already possible with some
configuration)
The current corridor deb package in Whonix repository should work fine on Debian hosts. It just needs testing, documentation and maintenance.
https://github.com/adrelanos/corridor
Tor traffic whitelisting gateway - Debian focussed fork of https://github.com/rustybird/corridor
sudo apt-get install corridor from Whonix repository. Installation from Debian repository would be better, but I don't know if that will happen.
Debian request for package (RFP):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829740
That is not how Debian packages are usually made. Once you install them, they start providing their functionality. Servers automatically start etc.
OK.
On second thought not including it in the misc package is better because its a full project and not a minor configuration file change.
The current corridor deb package in Whonix repository should work fine on Debian hosts. It just needs testing, documentation and maintenance.
Sounds good. I'll test.
If I setup the Whonix repo url with apt-transport-tor I should be ok?
Just install corridor on the host and configure it as a host firewall (already possible with some configuration)
Its as simple as running a single command? Does this conflict with ufw?
To remove these rules I can uninstall and restart. What about temporarily disabling corridor to access local resources, how can I do that? (useful for me to include in the documentation).
...Perhaps also install sdwdate.
Can these be technically installed right now stand-alone ? - (but need some testing for leak checks that corridor can now do)
I think creating more packages canbe time consuming and probably not useful unless the host relevant packages start to sprawl.
Yes.
The current corridor deb package in Whonix repository should work fine on Debian hosts. It just needs testing, documentation and maintenance.
Sounds good. I'll test.
If I setup the Whonix repo url with apt-transport-tor I should be ok?
Yes.
Just install corridor on the host and configure it as a host firewall (already possible with some configuration)
Its as simple as running a single command?
According to rustybird, it is.
Does this conflict with ufw?
Dunno. Asked upstream.
clarify compatibility with ufw
https://github.com/rustybird/corridor/issues/26
To remove these rules I can uninstall and restart. What about temporarily disabling corridor to access local resources, how can I do that? (useful for me to include in the documentation).
Good question. I think this needs to be tested.
canonical, corridor specific:
sudo service corridor-init-forwarding stop sudo service corridor-init-snat stop
Very similar to this very chapter which is not very specific to Whonix:
https://www.whonix.org/wiki/Dev/Firewall_Refactoring#How_to_refactor_the_firewall_script_while_being_sure_there_are_no_iptables_changes
generic, crude, developers only:
https://www.whonix.org/wiki/Dev/Firewall_Unload
Not sure what you meant by local resources. Local connections? LAN connections?
...Perhaps also install sdwdate.
Can these be technically installed right now stand-alone ?
Theoretically yes, but there is no maintainer, not regularity tested by me.
- (but need some testing for leak checks that corridor can now do)
I think creating more packages canbe time consuming and probably not useful unless the host relevant packages start to sprawl.
Not sure what you meant by local resources. Local connections? LAN connections?
Yes LAN connections.
I'll gamble and test this. I think your service stop instruction will be enough to temporarily disable it.
HulaHoop (HulaHoop):
HulaHoop added a comment.
> Not sure what you meant by local resources. Local connections? LAN connections? Yes LAN connections.
Try first if LAN connections are blocked at all. I am not sure they are.
And even if these were blocked, it would be better to add an additional
iptables rule to allow these rather than totally disabling the firewall.
I was editing the Whonix packages on Debian host page and you added some changes half way through that almost blew my cover.
My instructions are for anonymously adding the Whonix repos. Most of the new stuff added goes against this. Should I make a new section for this?
HulaHoop (HulaHoop):
HulaHoop added a comment.
I was editing the Whonix packages on Debian host page and you added some changes half way through that almost blew my cover.
Sorry, I just saw an anonymous edit and it reminded me to use wiki
templates so instructions are consistent everywhere.
My instructions are for anonymously adding the Whonix repos. Most of the new stuff added goes against this. Should I make a new section for this?
Use the wiki template.
https://www.whonix.org/wiki/Template:Whonix-APT-Repository-Add
Introductions about options and two sections with expand buttons.
One:
clear http non-annymous apt
Two:
apt-transport-tor and Whonix hidden service for apt
No luck. Seems it depends on qubes processes that don't exist:
● corridor-init-forwarding.service - corridor's forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enable Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d └─qubes-service.conf, qubes.conf Active: inactive (dead)Condition: start condition failed at Sat
ConditionPathExists=/var/run/qubes-service/corridor was not met
Fow now:
sudo touch /var/run/qubes-service/corridor
And restart systemd services.
I think of something to solve this.
Or...
sudo rm /lib/systemd/system/corridor.target.d/qubes-service.conf
...and reboot should also help.
delete qubes/systemd/corridor.target.d/qubes-service.conf
https://github.com/rustybird/corridor/pull/27
I will make them into a template.
One: clear http non-annymous apt
Keeping in line with our safe defaults policy, what is the benefit of adding this? The number of people connecting directly to Whonix repos is so small that it would be very noticed.
I guess if you want to consider server admin needs it would make sense not to rely on TBB but the answer for that is to download the key using gpg from a HS keyserver:
https://lists.gnupg.org/pipermail/gnupg-announce/2015q4/000381.html
dirmngr: New option --use-tor. For full support this requires libassuan version 2.4.2 and a patched version of libadns (e.g. adns-1.4-g10-7 as used by the standard Windows installer).
(Needs to be confirmed if dependencies met in Debian for this to happen safely)
EDIT:
Or we can tell them to use Whonix to download the key.
I like that more because less effort.
HulaHoop (HulaHoop):
HulaHoop added a comment.
I will make them into a template.
One: clear http non-anonymous apt
Keeping in line with our safe defaults policy, what is the benefit of
adding this? The number of people connecting directly to Whonix repos
is so small that it would be very noticed.
Usability. Clear http non-anonymous apt is a lot simpler to set up.
And if https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP
does not apply, not really needed.
And if one wanted to go for Hide_Tor_and_Whonix_from_your_ISP, then this
would be difficult since the Debian Tor package automatically connects
to the public Tor network. They would have to configure bridges [or
else] before installing Tor from Debian.
As for security, just using Whonix onion apt may have no benefits if not
using onion apt for everything. (Related to: T399)
I guess if you want to consider server admin needs
No server admin needs. Not sure what you mean by that.
it would make
sense not to rely on TBB but the answer for that is to download the
key using gpg from a HS keyserver:https://lists.gnupg.org/pipermail/gnupg-announce/2015q4/000381.html
dirmngr: New option --use-tor. For full support this requires
libassuan version 2.4.2 and a patched version of libadns (e.g.
adns-1.4-g10-7 as used by the standard Windows installer).(Needs to be confirmed if dependencies met in Debian for this to
happen safely)
Yes, hiding all, including the signing key download through Tor is
difficult, but worthwhile.
Or...sudo rm /lib/systemd/system/corridor.target.d/qubes-service.conf
...and reboot should also help.
Unfortunately nothing good:
● corridor-init-forwarding.service - corridor's forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d └─qubes-service.conf, qubes.conf Active: failed (Result: exit-code) since SatMain PID: 1810 (code=exited, status=1/FAILURE)
Jul 23 17:23:08 debian systemd[1]: Starting corridor's forwarding...
Jul 23 17:23:08 debian corridor-init-forwarding[1810]: ipset v6.29: Cannot open session to kernel.
Jul 23 17:23:11 debian systemd[1]: corridor-init-forwarding.service: Main process exited, code=exited, status=1/FAILURE
Jul 23 17:23:11 debian systemd[1]: Failed to start corridor's forwarding.
Jul 23 17:23:11 debian systemd[1]: corridor-init-forwarding.service: Unit entered failed state.
Jul 23 17:23:11 debian systemd[1]: corridor-init-forwarding.service: Failed with result 'exit-code'.
Warning: corridor-init-forwarding.service changed on disk. Run 'systemctl daemon-reload' to reload units.
HulaHoop (HulaHoop):
> Jul 23 17:23:08 debian corridor-init-forwarding[1810]: ipset v6.29: Cannot open session to kernel.
Using Debian jessie?
Can you fix ipset on your system?
Somehow ipset is broken on your system. Debian
https://packages.debian.org/de/jessie/ipset ships 6.23-2. Version 6.29
perhaps comes from Debian stretch? I guess this is a case where mixing
Debian suites (here jessie and stretch) causes issues. Try to avoid
mixing. Use backports if possible, they should not be affected by such
issues.
Besides the other solution I tried earlier today
sudo touch /var/run/qubes-service/corridor
And restart systemd services.
gives:
touch: cannot touch '/var/run/qubes-service/corridor': No such file or directory
Using Debian jessie?
No on Stretch. I forgot to mention that...
Can you fix ipset on your system?
Somehow ipset is broken on your system. Debian https://packages.debian.org/de/jessie/ipset ships 6.23-2. Version 6.29 perhaps comes from Debian stretch? I guess this is a case where mixing Debian suites (here jessie and stretch) causes issues. Try to avoid mixing. Use backports if possible, they should not be affected by such issues.
What can I do to avoid this besides downgrading which is a huge hassle?
> touch: cannot touch '/var/run/qubes-service/corridor': No such file or directory
Beforehand:
sudo mkdir /var/run/qubes-service
HulaHoop (HulaHoop):
Why not set the ipset dependency to >=6.23-2 ?
There is no versioned dependency. Upstream assumes "ipset just works".
Debian packaging declared "ipset any version".
I think ipset is broken on your system without corridor being involved
at all.
Ok so manually installed ipset from jessie should fix it?
No. Mixing stretch with jessie packages would create a bigger mess.
Don't. The ipset version you have has to be made to work.
What can I do to avoid this besides downgrading which is a huge hassle?
Fix ipset. Must be a configuration issue or Debian bug etc.
● corridor-init-forwarding.service - corridor's forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d
└─qubes-service.conf, qubes.conf
Active: active (exited) since Sun
Process: 3570 ExecStart=/bin/rm -f /var/run/qubes-service/qubes-firewall (code=exited, status=0/SUCCESS)
Process: 3541 ExecStart=/usr/sbin/corridor-init-forwarding (code=exited, status=0/SUCCESS)Main PID: 3570 (code=exited, status=0/SUCCESS)
Jul 24 00:10:20 debian systemd[1]: Starting corridor's forwarding...
Jul 24 00:10:20 debian corridor-init-forwarding[3541]: net.ipv4.ip_forward = 1
Jul 24 00:10:20 debian corridor-init-forwarding[3541]: net.ipv6.conf.all.forwarding = 0
Jul 24 00:10:20 debian systemd[1]: Started corridor's forwarding.
Corridor testing:
Good news:
Got it working with the workarounds.
Bad news:
Two solutions come to mind: adding a LAN permission option to corridor for manual use. Out of scope of this ticket but an interesting topic that should be discussed: add a barebones captive portal responder on the host under its own user account that is exempted by corridor. This keeps leaks absolutely minimal and reduces attack surface when having to deal with captive portals.
Update of corridor v0.10.0 uploaded to Whonix repository just now. Please update.
Please also install the usability-misc package from Whonix repository since it provides the iptables-save-deterministic command or get it from elsewhere.
Look how the chains are named in your local iptables rules. Compare with those from corridor iptables commands from corridor source code.
sudo iptables-save-deterministic
OK reinstalled new version from scratch.
Got the qubes service error still:
● corridor-init-forwarding.service - corridor's forwarding
Loaded: loaded (/lib/systemd/system/corridor-init-forwarding.service; enabled; ve
Drop-In: /lib/systemd/system/corridor-init-forwarding.service.d
└─qubes-service.conf, qubes.conf
Active: inactive (dead)Condition: start condition failed
ConditionPathExists=/var/run/qubes-service/corridor was not met
I'll apply the workaround and see what else changed.
ConditionPathExists=/var/run/qubes-service/corridor was not met
Reported this here now:
https://github.com/rustybird/corridor/pull/27#issuecomment-236368253
It might help to attach the output of iptables-save-deterministic to https://github.com/rustybird/corridor/issues/28. I attach mine below. Yours should look similar. Slight differences may happen due to Qubes vs Debian configuration.
sudo iptables-save-deterministic
*nat :PREROUTING ACCEPT [0,0] :INPUT ACCEPT [0,0] :OUTPUT ACCEPT [0,0] :POSTROUTING ACCEPT [0,0] :CORRIDOR_SNAT - [0,0] -A POSTROUTING -j CORRIDOR_SNAT -A CORRIDOR_SNAT -s 10.137.0.0/16 ! -d 10.137.0.0/16 -j MASQUERADE COMMIT *filter :INPUT ACCEPT [0,0] :FORWARD ACCEPT [0,0] :OUTPUT ACCEPT [0,0] :CORRIDOR_FILTER - [0,0] -A FORWARD -j CORRIDOR_FILTER -A CORRIDOR_FILTER -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN -A CORRIDOR_FILTER -m set --match-set corridor_relays dst,dst -j RETURN -A CORRIDOR_FILTER -m set --match-set corridor_logged src -j LOG --log-prefix "corridor: reject " --log-macdecode -A CORRIDOR_FILTER -j REJECT --reject-with icmp-host-prohibited COMMIT
Tried doing a clean install of 0.10.0-2. The installation process hangs indefinitely after the last step. I am not able to remove the package because dpkg insists that its still installing:
Setting up corridor (0.10.0-2) ...
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-logged.service → /lib/systemd/system/corridor-init-logged.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-snat.service → /lib/systemd/system/corridor-init-snat.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-data.service → /lib/systemd/system/corridor-data.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
Created symlink /etc/systemd/system/systemd-networkd.service.requires/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
Created symlink /etc/systemd/system/multi-user.target.wants/corridor.target → /lib/systemd/system/corridor.target.
What hangs? Check processes / process trees.
ps aux
Would be good to know.
Also check the "sudo service ... status" of all corridor services.
(Documented on corridor wiki page.) Or perhaps journalctl -u ... for all
of them.
Does reboot help? Perhaps it's just related to the
/var/run/qubes-service/corridor bug fix update.
Also standard Debian ways for removal of broken Debian packages "dpkg
force all" would work.
Enabling verbosity of the maintainer scripts at least the postinst
script might help. For the latter create a file:
/usr/lib/pre.bsh
contents:
set -x
Then during installation we should have more debug output.
Postinst verbose:
Preparing to unpack .../corridor_0%3a10.0.0-3_all.deb ...
Unpacking corridor (10.0.0-3) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up corridor (10.0.0-3) ...
+ set -e
+ true '
'
+ case "$1" in
+ mkdir --parents /var/lib/corridor
+ true 'INFO: debhelper beginning here.'
+ deb-systemd-helper unmask corridor-init-logged.service
+ deb-systemd-helper --quiet was-enabled corridor-init-logged.service
+ deb-systemd-helper enable corridor-init-logged.service
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-logged.service → /lib/systemd/system/corridor-init-logged.service.
+ deb-systemd-helper unmask corridor-init-snat.service
+ deb-systemd-helper --quiet was-enabled corridor-init-snat.service
+ deb-systemd-helper enable corridor-init-snat.service
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-snat.service → /lib/systemd/system/corridor-init-snat.service.
+ deb-systemd-helper unmask corridor-data.service
+ deb-systemd-helper --quiet was-enabled corridor-data.service
+ deb-systemd-helper enable corridor-data.service
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-data.service → /lib/systemd/system/corridor-data.service.
+ deb-systemd-helper unmask corridor-init-forwarding.service
+ deb-systemd-helper --quiet was-enabled corridor-init-forwarding.service
+ deb-systemd-helper enable corridor-init-forwarding.service
Created symlink /etc/systemd/system/multi-user.target.wants/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
Created symlink /etc/systemd/system/systemd-networkd.service.requires/corridor-init-forwarding.service → /lib/systemd/system/corridor-init-forwarding.service.
+ deb-systemd-helper unmask corridor.target
+ deb-systemd-helper --quiet was-enabled corridor.target
+ deb-systemd-helper enable corridor.target
Created symlink /etc/systemd/system/multi-user.target.wants/corridor.target → /lib/systemd/system/corridor.target.
+ '[' -d /run/systemd/system ']'
+ systemctl --system daemon-reload
+ deb-systemd-invoke start corridor-init-logged.service corridor-init-snat.service corridor-data.service corridor-init-forwarding.service corridor.target
sudo journalctl -u corridor*
25 debian systemd[1]: Started corridor's relay list.
25 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
25 debian corridor-data[1917]: :25 socat[1923] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
26 debian systemd[1]: Starting corridor's forwarding...
26 debian systemd[1]: Starting corridor's logging...
26 debian systemd[1]: Starting corridor's source NAT...
27 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
27 debian corridor-data[1917]: :27 socat[1949] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
27 debian systemd[1]: Started corridor's source NAT.
28 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
28 debian corridor-data[1917]: :28 socat[1993] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
28 debian corridor-init-forwarding[1936]: net.ipv4.ip_forward = 1
28 debian corridor-init-forwarding[1936]: net.ipv6.conf.all.forwarding = 0
28 debian systemd[1]: Started corridor's forwarding.
29 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
29 debian corridor-data[1917]: :29 socat[2032] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
30 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
30 debian corridor-data[1917]: :30 socat[2057] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
31 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
31 debian corridor-data[1917]: :31 socat[2068] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
32 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
32 debian corridor-data[1917]: :32 socat[2093] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
33 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
33 debian corridor-data[1917]: :33 socat[2195] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
34 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
34 debian corridor-data[1917]: :34 socat[2212] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
35 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
35 debian corridor-data[1917]: :35 socat[2228] E connect(5, AF=1 "/var/run/tor/control", 22): No such file or directory
36 debian corridor-data[1917]: /usr/sbin/corridor-data: 39: /usr/sbin/corridor-data: cannot open /var/run/tor/control.authcookie: No such file
52 debian corridor-data[1917]: 515 Authentication failed: Wrong length on authentication cookie.
53 debian corridor-data[1917]: :53 socat[3031] E write(1, 0x2551aa0, 7963): Broken pipe
55 debian corridor-data[1917]: :55 socat[3072] E write(1, 0x853aa0, 7963): Broken pipe
56 debian corridor-data[1917]: :56 socat[3101] E write(1, 0x1235aa0, 7963): Broken pipe
57 debian corridor-data[1917]: :57 socat[3119] E write(1, 0x1de4aa0, 7963): Broken pipe
59 debian corridor-data[1917]: :59 socat[3127] E write(1, 0x10daaa0, 7963): Broken pipe
00 debian corridor-data[1917]: :00 socat[3138] E write(1, 0x14eeaa0, 7963): Broken pipe
01 debian corridor-data[1917]: :01 socat[3148] E write(1, 0x2668aa0, 7963): Broken pipe
03 debian corridor-data[1917]: :03 socat[3161] E write(1, 0xee1aa0, 7963): Broken pipe
04 debian corridor-data[1917]: :04 socat[3189] E write(1, 0x80daa0, 7963): Broken pipe
05 debian corridor-data[1917]: :05 socat[3206] E write(1, 0x1b9caa0, 7963): Broken pipe
07 debian corridor-data[1917]: :07 socat[3218] E write(1, 0xecfaa0, 7963): Broken pipe
08 debian corridor-data[1917]: :08 socat[3245] E write(1, 0x2072aa0, 7963): Broken pipe
09 debian corridor-data[1917]: :09 socat[3272] E write(1, 0x1e36aa0, 7963): Broken pipe
11 debian corridor-data[1917]: :11 socat[3298] E write(1, 0x9f0aa0, 7963): Broken pipe
12 debian corridor-data[1917]: :12 socat[3315] E write(1, 0xfb3aa0, 7963): Broken pipe
13 debian corridor-data[1917]: :13 socat[3338] E write(1, 0x1845aa0, 7963): Broken pipe
15 debian corridor-data[1917]: :15 socat[3359] E write(1, 0x705aa0, 7963): Broken pipe
16 debian corridor-data[1917]: :16 socat[3370] E write(1, 0xe9eaa0, 7963): Broken pipe
17 debian corridor-data[1917]: :17 socat[3377] E write(1, 0xf7daa0, 7963): Broken pipe
19 debian corridor-data[1917]: :19 socat[3394] E write(1, 0x1d6eaa0, 7963): Broken pipe
20 debian corridor-data[1917]: :20 socat[3413] E write(1, 0x1dd6aa0, 7963): Broken pipe
22 debian corridor-data[1917]: :22 socat[3422] E write(1, 0x2034aa0, 7963): Broken pipe
lines 1-53
sudo systemctl status corridor*
● corridor-init-logged.service - corridor's logging
Loaded: loaded (/lib/systemd/system/corridor-init-logged.service; enabled; vendor
Drop-In: /lib/systemd/system/corridor-init-logged.service.d
└─qubes-service.conf, qubes.conf
Active: activating (start) sinceMain PID: 5776 (corridor-init-l)
CGroup: /system.slice/corridor-init-logged.service
├─5776 /bin/sh -e /usr/sbin/corridor-init-logged
└─8636 sleep 1debian systemd[1]: Starting corridor's logging...
Probably two things here.
1) I reported some bugs upstream that might fix this.
2)
Do you have Tor running?
sudo service tor status
sudo service tor@default status
Did Tor create the required files?
sudo ls -la /var/run/tor/control
sudo ls -la /var/run/tor/control.authcookie
These are owned by user/group debian-tor?
On Debian the Tor control socket should already be set up by default.
cat /usr/share/tor/tor-service-defaults-torrc
DataDirectory /var/lib/tor PidFile /var/run/tor/tor.pid RunAsDaemon 1 User debian-tor ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie Log notice file /var/log/tor/log
If it hangs at deb-systemd-invoke, as a workaround you should be able to just kill that process.
sudo killall deb-systemd-invoke
Or search the pid with ps aux or some other process manager and sigterm/sigkill it as root. Verify it was really terminated. Then the postinst and package installation should successfully continue. That should be good enough for reboot and test how it works.
Results: Tor is running properly the auth cookie exists and the torrc file looks sane.
I think its the order of service initialization that rusty talks about that is causing this. I'll wait for the newer version by rusty to be uploaded before I test again.
HulaHoop (HulaHoop):
HulaHoop added a comment.
Results: Tor is running properly the auth cookie exists and the torrc file looks sane.
Good.
I think its the order of service initialization that rusty talks about that is causing this. I'll wait for the newer version by rusty to be uploaded before I test again.
That new version will only have cosmetic advantages. Better looking logs.
Will likely not solve any other issues you are having. Most likely will
not solve any issues you could not solve by manually restarting corridor
systemd services after the system finished booting.
Therefore, no need to wait for that reason. Testing, debugging, upstream
bug reporting now is as good as later.
I somehow doubt rustybird is going to move this forward because rustybird is a Qubes host, not Debian host user. Without third party contributions to corridor, probably not going to happen. (Meanwhile other Qubes specific software was released, split-browser for Qubes.)