Oct 24 2023
Apr 6 2019
May 12 2018
meek might be dead by then:
https://forums.whonix.org/t/replacing-meek-snowflake
Feb 6 2018
Sep 7 2017
Sep 6 2017
Ah I see.
Sep 5 2017
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
I changed it to NoNewPrivileges=No That's the only thing I can imagine that would be causing that parsing error. Testing now > torproject's stretch repository [1] does not contain tor_0.3.1.5 yet. Once TPOs stretch repo contains the latest, this workaround will no longer be needed, correct?
Sep 4 2017
with =no, I'm no longer getting the parsing error
I changed it to
NoNewPrivileges=No
That's the only thing I can imagine that would be causing that parsing error. Testing now
Sep 3 2017
Jul 6 2017
Please keep the Whonix 14 tag. I guess this can be closed, resolved?
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
Ok I created the workaround as you described: https://github.com/Whonix/anon-gw-anonymizer-config/commit/bfe28e340d03cc4d77e4f49e24bcc0a9da42da06
Jul 5 2017
Debian bug report:
Ok I created the workaround as you described:
https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/lib/systemd/system/tor@default.service.d/40_obfs4proxy-workaround.conf
Jul 1 2017
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.
Two things work:
- Changing obfs4 execution permission in system_tor apparmor profile
(abstractions/tor) from PUx to ix.
- Keeping PUx but removing "NoNewPrivileges" from tor@default
systemd service (/lib/systemd/system)
Two things work:
Jun 30 2017
Pux (already Tor's default) is alright.
I commented out the lines in local/system_tor about obfsproxy. This caused obfsproxy to fail. Changing obfsproxy to rix didn't work. But I'm confused at what I'm seeing, and so I'm still looking at it.
Comment that and obfs4proxy can run as PUx (instead of needing ix)
Jun 29 2017
To save you from somehow learning about systemd overrides the hard way...
In this case, a /local file can probably not do the trick.
Ah. I didn't see the include. Makes sense.
/etc/apparmor.d/system_tor after #include <abstractions/tor> and #include <local/system_tor> will be interpreted like the following, I think:
But what I really don't know is how system_tor interacts with abstractions/
Jun 28 2017
AA doesn't report a denied message when tor tries to launch obfs4. However:
Jun 26 2017
Yes. Because the other solution "not use AppArmor for Tor" is not a great one. It worked in Whonix 13, just needs to be fixed for Whonix 14.
To be clear:
Tor ships a broken apparmor profile (for the last 5 years? Suggested nuke of the profile 3 years ago), and we're trying to unbreak obfs4, correct?
/etc/apparmor.d/system_tor is unmodified, owned by Debian tor packabe. /etc/apparmor.d/system_tor Will #include <local/system_tor>.
Which app armor profile is blocking obfs4? Something from us or an apparmor profile that comes from tpo?
Jun 22 2017
That's why we need to sort it out in https://github.com/Whonix/apparmor-profile-anondist/blob/master/etc/apparmor.d/abstractions/base.anondist somehow.
Tor's own app armor profile breaks needed features (obs4). The ticket is 4 years old with no progress. Even they complained about needed to resolve or remove it (years ago).
Jun 5 2017
Jun 3 2017
You're right. /var/run/tor/log reports
"Could not launch managed proxy executable /usr/bin/obfs4proxy Operation not permitted"
Is the obfs4proxy package installed? Probably yes.
Jun 2 2017
I was trying obfs4proxy in whonix-gateway. I editted the torrc to UseBridges 1 and added the Client Transport line (note, torrc.examples says to add "managed" at the end; https://github.com/Yawning/obfs4 does not). I then added bridges from tpo (bridge obfs4 ip ... ).
Whonixcheck reports WARNING can't connect to bridge REASON=PT_MISSING
PT_Missing is an error from stem: "no pluggable transport was available"
May 16 2017
Feb 11 2017
Not easy. Need to wait for reply from TPO.
Jan 18 2017
Jan 15 2017
Didn't make it into Debian version 9 codename Stretch. Rechecking in Debian version 10 codename Buster.