Hello,
Did you try running obfs4proxy on Debian Buster or Bullseye and it worked?
For me it stopped working entirely. All it says is:
[warn] Pluggable Transport process terminated with status code 256
Here is what I checked so far:
- I am on Debian Bullseye with all packages up to date
- go lang version is go1.15.9 linux/amd64
- obfs4proxy version is obfs4proxy-0.0.12-dev (compiled from git)
- Tor version is 0.4.7.0-alpha-dev
I have edited /lib/systemd/system/tor@default.service & tor@.service to NoNewPrivileges=no and also installed libcap2-bin and setcap +ep to obfs4proxy executable. The libcap2-bin step is because I want to bind to a lower port, but even if I try to bind to a higher port like 50001 it will still not work and report the same:
Pluggable Transport process terminated with status code 256.
On another server I did a software upgrade from stretch to buster by apt dist upgrade and obfs4proxy stopped working as well. I am still digging here cause there are chances I did some mistakes while upgrading, so I am just mentioning the Bullseye problem because there are no excuses there, it should work, it's a clean fresh new install from scratch.
Can someone please have another look to see if the problem is just on my side or if it's persistent among Bullseye installs, we should update the wiki bridge howto. Thanks.
s7r wrote:
I have edited /lib/systemd/system/tor@default.service & tor@.service to NoNewPrivileges=no and also installed libcap2-bin and setcap +ep to obfs4proxy executable. The libcap2-bin step is because I want to bind to a lower port, but even if I try to bind to a higher port like 50001 it will still not work and report the same:
Pluggable Transport process terminated with status code 256.
On another server I did a software upgrade from stretch to buster by apt dist upgrade and obfs4proxy stopped working as well. I am still digging here cause there are chances I did some mistakes while upgrading, so I am just mentioning the Bullseye problem because there are no excuses there, it should work, it's a clean fresh new install from scratch.
Can someone please have another look to see if the problem is just on my side or if it's persistent among Bullseye installs, we should update the wiki bridge howto. Thanks.
Hello,
I think it has something to do with our hardening configuration. On Debian Bullseye, I start my bridge with log info and I get:
[info] process_exec(): Starting new process: /usr/local/bin/obfs4proxy [info] launch_managed_proxy(): Managed proxy at '/usr/local/bin/obfs4proxy' has spawned with PID '1856'.
When I start the bridge (using systemd/systemctl), there are no Tor processes or obfs4proxy processes running on the machine.
After it logs that info that it has spawned with another PID, I can find that PID in my system as DEFUNCT.
# ps aux | grep tor debian-+ 1855 91.9 5.7 243532 230668 ? Rs 17:28 0:15 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 debian-+ 1856 5.2 0.0 0 0 ? Z 17:28 0:00 [tor] <defunct>
Wonder what is causing this. I am using the default install from deb.tp.o just with NoNewPrivileges=no to tor@default.service and tor@.service.
I also find it buggy that this is at info level.
s7r wrote:
Hello,
I think it has something to do with our hardening configuration. On Debian Bullseye, I start my bridge with log info and I get:
[info] process_exec(): Starting new process: /usr/local/bin/obfs4proxy [info] launch_managed_proxy(): Managed proxy at '/usr/local/bin/obfs4proxy' has spawned with PID '1856'.
When I start the bridge (using systemd/systemctl), there are no Tor processes or obfs4proxy processes running on the machine.
After it logs that info that it has spawned with another PID, I can find that PID in my system as DEFUNCT.
# ps aux | grep tor debian-+ 1855 91.9 5.7 243532 230668 ? Rs 17:28 0:15 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 debian-+ 1856 5.2 0.0 0 0 ? Z 17:28 0:00 [tor]
<defunct>
Wonder what is causing this. I am using the default install from deb.tp.o just with NoNewPrivileges=no to tor@default.service and tor@.service.
I also find it buggy that this is at info level.
Fixed it. this was due to apparmor incorrect settings.
The obfs4proxy process was being killed by apparmor:
audit[2994]: AVC apparmor="DENIED" operation="exec" profile="system_tor" name="/usr/local/bin/obfs4proxy" pid=2994 comm="tor" requested_mask="x" denied_mask="x" fsuid=107 ouid=0
kernel: audit: type=1400 audit(1630685584.124:19): apparmor="DENIED" operation="exec" profile="system_tor" name="/usr/local/bin/obfs4proxy" pid=2994 comm="tor" requested_mask="x" denied_mask="x" >
And this is because my obfs4proxy executable was installed in a different path than /usr/bin/obfs4proxy which is in the "deafult" shipped apparmor settings for Tor.
All I had to do was to edit /etc/apparmor.d/abstractions/tor
and change from:
/usr/bin/obfs4proxy Pix,
to
/usr/local/bin/obfs4proxy Pix,
and
$ sudo service apparmor reload
And it worked. This extra step is in addition to setcap +ep obfs4proxy and NoNewPrivileges=no in /lib/systemd/system/tor@default.service and /lib/systemd/system/tor@.service and it's only necessary if you install obfs4proxy (or other pluggable transport) in a different location that /usr/bin/$transport, otherwise it works normally.
Thanks for reading and sorry about the noise. Logged https://gitlab.torproject.org/tpo/core/tor/-/issues/40459 to improve the wiki and maybe escalade the log level for those two messages.
tor-relays@lists.torproject.org
-
s7r