This will be done when doing T927.

Awesome!

I created the issue:

https://github.com/Whonix/apparmor-profile-everything/pull/7

Could you add to git please?

Works.

Try adding:

Ah I see.

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?

In T676#14449, @JasonJAyalaP wrote:

with =no, I'm no longer getting the parsing error

sudo journalctl | grep workaround

but /lib/systemd/system/tor@default.service is unaffected

# Hardening
AppArmorProfile=system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
...

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

In T676#14015, @JasonJAyalaP wrote:

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

Thanks for updating me! No, then this needs to be removed. And the sandboxed tor browser chanter moved to https://www.whonix.org/wiki/Deprecated.

According to their wiki that you linked to: "Active development is on indefinite hiatus." Do you still want FP to talk about and link to that?

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

After FoxyProxy is installed, you may see an app-armory warning you

about the denied creation of dconf/user. The current Debian profile for
Firefox does not yet include the modern temporary file location /run/user.

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

@Patrick 
the FP template says "Tor Browser will soon ship with sandboxing on an opt-in basis." Wasn't this rejected?

JasonJAyalaP (Jason J. Ayala P.):

the FP template says "Tor Browser will soon ship with sandboxing on an opt-in basis." Wasn't this rejected?

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

@Patrick
the FP template says "Tor Browser will soon ship with sandboxing on an opt-in basis." Wasn't this rejected?

Reported but to app armor:
https://bugs.launchpad.net/apparmor/+bug/1702360

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

Two things work:

1. Changing obfs4 execution permission in system_tor apparmor profile

(abstractions/tor) from PUx to ix.

2. Keeping PUx but removing "NoNewPrivileges" from tor@default

systemd service (/lib/systemd/system)

JasonJAyalaP (Jason J. Ayala P.):

But it should be apart of abstractions/user-tmp. Are you comfortable doing this, Patrick?

I really think that "access to the temp folder" should be a basic AA allowance. In fact, it is right now with #include user-tmp. However, user-tmp is so old (I'm guessing) it doesn't have /run/user/[0-9]/**

Ok, the line should be:

I get the message after a reboot.

Ok. I added the commented line to home.tor-browser.firefox

Two things work:

Pux (already Tor's default) is alright.

In T662#13958, @JasonJAyalaP wrote:

Ahh I see. I can setup i2p/freenet/zeronet and use FP to go through that.

I got zeronet working and browsing around. Latest aa profiles, aa-notify -p, journctl -f

No denied messages.

Ahh I see. I can setup i2p/freenet/zeronet and use FP to go through that.

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)

To save you from somehow learning about systemd overrides the hard way...

In this case, a /local file can probably not do the trick.

In T676#13872, @JasonJAyalaP wrote:

Ah. I didn't see the include. Makes sense.

A local proxy should do. Use any of these guides.

Ah. I didn't see the include. Makes sense.

Do you got a proxy I can configure it to use? Still waiting for him to reply.

/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/

I cant get latest FP on latest TB to actually use that file (and generate an error). I'm not sure what torjunkie does to trigger it.

FP replied

Sorry, but we have no idea what dconf/settings is. FoxyProxy does not read or write to such a file

owner /run/user/[0-9]*/dconf/user rw

What do the other AA profiles do with the /run/user/1000? We give them access to 1000/APPNAME only?

I opened a ticket on the FoxyProxy system:

Probably hasn't solved itself.

You told him it wasn't a problem. But if you think it's worth it, alright.

AA doesn't report a denied message when tor tries to launch obfs4. However:

Probably hasn't solved itself. This bug report presupposes quite a lot knowledge, isn't well described. Reproduction isn't obvious since it has two prerequisites. To explain what this is about and required for reproduction:

I'll talk with torjunkie in the forum. I'll close this ticket because it's not a whonix 14 blocker, and every AA fix can't have its own ticket

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>.

In T676#13825, @JasonJAyalaP wrote:

Which app armor profile is blocking obfs4?

Which app armor profile is blocking obfs4? Something from us or an apparmor profile that comes from tpo?

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).

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.

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"

https://github.com/Whonix/apparmor-profile-torbrowser/commit/9032e909c2b10e20ecf104d4eb1acc120df167d1

https://github.com/Whonix/Whonix/commit/692b29b15aa33fc5b0c431d6bf0f3c2d5c1242fd

Not easy. Need to wait for reply from TPO.

https://github.com/Whonix/anon-meta-packages/commit/4385dbdd54f68b0855cbc20574b9faa2d2f8a83e

timesync and apparmor-profile-timesync were deprecated so this task in invalid.