7.0a3 Tor Browser Series -> Defunct in Whonix

Support
1

1) Tor Browser 6.5.2 with Apparmor

Runs like a dream. Including in a Whonix-WS DisposableVM.

2) Tor Browser 7.0a3 without Apparmor on Whonix-Workstation

Partially Works:

  • Websites OK.
  • Tor Project IP address check OK
  • .onions work.

But:

  • Tor Button Missing in Action (doesn’t appear), so can’t change security slider.
  • Can’t interact with add-ons e.g preferences, updating fails with a HTTPS error.
  • Seems to be running in low security slider (default) mode.
  • Search engines dead, etc.

That is, not useable.

3) Tor Browser 7.0a3 without AppArmor on Whonix-Workstation and Whonix-Gateway

Exactly as above, defunct and not safely useable.

4) Tor Browser 7.0a3 running AppArmor on Whonix-Workstation and Whonix-Gateway

Doesn’t work at all:

  • Whonix landing page doesn’t even appear.
  • Can’t load any webpages at all.
  • Apparmor goes crazy with:

apparmor=“DENIED” operation=“open” profile="/home/**/tor-browser*/Browser/firefox" name="/proc/1923/net/route" pid=[redacted] comm=[redacted crazy numbers and letters] requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0

x1

apparmor=“DENIED” operation=“mknod” profile="/home/**/tor-browser*/Browser/firefox" name="/dev/shm/org.chromium.FzXY5G" pid=[redacted] comm=[redacted crazy numbers and letters] requested_mask=“c” denied_mask=“c” fsuid=1000 ouid=1000

x a million messages.

Conclusions

Based on the scientific method from 1, 2, 3, and 4 above:

  • Tor Browser AppArmor settings are a problem with the alpha series.
  • ESR 52 (7.0a3 series) is currently incompatible with Whonix (no idea why).
  • Logs aren’t showing any errors for tests 2 & 3 to provide more info.
  • Users should stick to 6.5.2 for the time being, which also works fine in a DisposableVM & works with AppArmor.
  • Note that the ESR 52 nightly from 6th April worked in Whonix (I checked, see wiki edits thread). So, something changed between then and now to break Whonix completely. e10s? Others?

General Comments

Considering how many “critical” and “high” severity bugs were identified in this Tor Browser release, it might be time to try v0.0.6 of the sandboxed tor-browser again. Although, the upstream issue hasn’t been fixed for Qubes as I understand it.

With Debian Stretch almost due for release perhaps Whonix 14 isn’t far away too i.e. the updated port filter that was required for the sandbox?

1 Like
2

Moved from the Long wiki edits thread.

Re: Tor Browser ESR 52.0.2 Nightly Test

The ESR 52 nightly build is from the 6th April, so hopefully they have fixed many of these issues / bugs below.

https://lists.torproject.org/pipermail/tbb-dev/2017-April/000501.html

We have first nightly builds based on Firefox 52.0.2esr available:

Index of /~gk/testbuilds/tbb-nightly

The location is a bit unusual but we hit an issue in our nightly build Gitian setup which made some tweaking to our usual build and upload process necessary. Nevertheless, please give this nightly a test if you can as we don’t have much time left before the first alpha based on ESR 52 is due.

Test Outcome

Tested and (mostly) working in Whonix!

Some problems

  • There is some weird maximizing windows behaviour when checking the “About Tor” button and Add-ons settings (already reported to Tor Project), but it confirms it is FF ESR 52.0.2.
  • They haven’t disabled Pocket yet.
  • The Youtube test hangs first time when the security slider is set to medium (but got it working eventually).
  • Restart Browser (New Identity) maximized and really didn’t want to restart unless the “x” button was hit. I had to manually kill another Tor Browser instance after the new Tor Browser popped up (due to the Youtube error).

This AppArmor message appears, but Tor Browser still works:

apparmor=“DENIED” operation=“open” profile=“/home/**/tor-browser*/Browser/firefox” name=“/proc/2616/net/route” pid=[redacted] comm=[redacted - long weird set of numbers and letters] requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0

Sandbox Options all read true

Seccomp-BPF (System Call Filtering) true
Seccomp Thread Synchronization true
User Namespaces true
Media Plugin Sandboxing true

e10s is (was) still not enabled in Linux

The Tor Project was still working on it at that time.

Multiprocess Windows 0/1 (Disabled)

Browser Fingerprinting.

JonDoNym, BrowserLeaks, Panopticlick etc. seem to treat it like the normal Tor Browser, that is, not much showing.

However, the fingerprint was completely unique out of 35,000 odd browsers on Panopticlick, since obviously nobody is (was) running Tor Browser ESR 52 in general.

General Other Tests

  • Restart Browser Test (but with quirks as noted) → works.
  • .onion Test → works (but notes .onions show an insecure padlock, go figure).
  • New Tor Circuit → works.
  • Updating Add-ons → works.
  • Youtube (but with quirks as noted) → works.
  • Online gaming (simple) → works.
  • Twitter > works.
  • Github → works.
  • Whonix.org → works.
  • Search engines → works
  • Other → Didn’t test.

Basically, it is useable in Whonix but very fingerprintable right now. This is particularly true since it wants to periodically maximize the window when you hit some of the menu options.

3

For sandboxed-tor-browser (manually installed in Whonix)…

Qubes unresolved issue, need to run:

sudo umount /proc/xen

( flatpak / bubblewrap fails to start - Can't mount proc on /newroot/proc - /proc/xen mount issue · Issue #2540 · QubesOS/qubes-issues · GitHub )

Whonix unresolved issue, needs newer version of control-port-filter-python (now onion-grater), that will come in Whonix 14, that is blocked by resolving the following tickets somehow Whonix 14 · Workboard as well as the Debian stretch being blessed stable.

Related, there is a another severe bug that stops us from using Tor Browser at all.
Tor Browser 7.0a2 broken in stretch based Whonix 14 - <jemalloc>: Corrupt redzone 0 bytes after 0x7f0503ede9d0 (size 80), byte=0x0

4

Does anyone think they could send a pull request for apparmor-profile-torbrowser/home.tor-browser.firefox at master · Kicksecure/apparmor-profile-torbrowser · GitHub to sort out these apparmor denied messages?

The issues you’ve been reporting… It would be very good to know which issues are only happening inside Whonix, and which ones are not. Like for example:

That works for me.

Does it work for you in a Qubes Debian jessie template? And is broken inside Whonix-Workstation? Then that would be a bug that Whonix could be responsible for. Otherwise such issues belong to the Tor Project issue tracker. (And very welcome being referenced here to stay up to date.)

What’s the difference between these test cases?

5

Good call.

Let me try and run Tor Browser in a standard Debian template in Qubes, then we have more information.

So you have some more functionality in non-Qubes-Whonix? That’s interesting if that’s the case.

Re: Apparmor -> yeah, probably no difference between those user cases (forgetting that all the profiles apply to the Workstation apps from memory).

1 Like
6

I didn’t say that in my previous post.

7

Test Platform:

Qubes Debian-8 AppVM Test.

Tor Browser Series:

Tor Browser 7.0a3
–debug mode from terminal

Other Settings:

  • Nil AppArmor settings or other hardening to interfere with the test.
  • Whonix-GW was not used, just the standard Qubes networking.

Functional Features:

  • Tor connects correctly.
  • A functional Tor Connection with check.torproject.org (“Test Tor Network Settings”).
  • About Tor Browser shows:

7.0a3 (based on Mozilla Firefox 52.1.0) (64-bit). “You are currently on the alpha update channel.”

  • Add-ons update correctly and the browser restarts fine.
  • Changing the security slider works.
  • DuckDuckGo and other https search engines work.
  • DuckDuckGo .onion search works.
  • Visible Tor Circuit works.
  • “New Tor Circuit for this Site” works.
  • “New Identity” works.
  • General website browsing works.
  • Youtube works. In fact the video seems much smoother than 45.9 ESR.
  • Whonix .onion and whonix.org are very smooth and fast, and those edits are looking fine. :wink:
  • Tested at the medium security level and segmentation faults (see below) seem to miraculously dissapear.
  • The sound works fine. None of the problems reported by some Gentoo Linux (and other platform) users appear for this alpha release.
  • Tested online Javascript gaming (basic) and it’s working nicely. In fact, ESR 52.1 has improved the video quality a lot. It is noticeable.
  • TBB debug output isn’t showing anything strange on the medium security level setting. Just some add-ons update manifest warnings which are nothing to worry about.
  • about:support shows e10s is running:

1/1 (Enabled by default)

  • Safe mode is off (as expected). Diagnose Firefox issues using Troubleshoot Mode | Firefox Help
  • Panopticlick shows (unfortunately) much more data being harvested at the medium level compared to the high security level e.g. Hash of canvas fingerprint, Screen Size and Color Depth, System Fonts, Touch Support Settings, Cookies enabled.
  • Other fingerprinting values are spoofed, but still a unique value is derived.

Browser Crashes:

The only two problems are these below. They are known to The Tor Project and related to this Tor Trac bug:

  • Changing/checking add-ons preferences crash the browser in high-security slider mode:

./start-tor-browser: line 368: 1098 Segmentation fault TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class “Tor Browser” -profile TorBrowser/Data/Browser/profile.default “${@}” < /dev/null

  • Tor Browser also occasionally crashes with the same segmentation fault (randomly) in high security slider mode e.g. when browsing. The output is like that above.

Qubes logs shows the crash in the plug-in container:

Chrome_ChildThr[1295]: segfault at 0 ip 0000000000405167 sp 00007f3102a7c400 error 6 in plugin-container[400000+40000]

Tor Browser Solution:

Running in medium security setting gives a solid and stable browsing experience and no repeat of segmentation faults.

Conclusion:

All in all, I am very pleasantly surprised that this works so well. 52.1 ESR seems to work in Qubes except for (bad) known Tor Project bugs.

In high security mode, this is their worst alpha release yet. But at the medium or low security slider mode, maybe it is their best (I sound like a salesperson). It is a very solid Tor browsing experience and has a nice feel to it given the improved video experience.

None of the other problems as seen in the Whonix AppVM emerge.

Preliminary Conclusion:

Since Tor Browser based on 52.1 ESR is running fine in a Qubes Debian AppVM, this suggests something is wrong with the Qubes-Whonix template settings (potentially also non-Qubes-Whonix, but I don’t run it).

This is probably unrelated to just Apparmor given earlier trials where this variable was removed.

Let me know if you want any further information or tests.

8

7.0a3 (based on Mozilla Firefox 52.1.0) (64-bit)

^ Copied from About Tor Browser.

Works for me in Qubes-Whonix-Workstation 13 based anon-whonix. (No AppArmor enabled.)

(Downloaded and installed using Tor Browser Downloader by Whonix. (update-torbrowser)

Could you try please if that works for you?

Are you sure that version version is broken?

You have mentioned Index of /~gk/testbuilds/tbb-nightly earlier. Perhaps that’s actually an older version that is broken?

And if you download from Index of /~gk/testbuilds/tbb-nightly, please make sure to use tor-browser-linux64-debug.zip. (The 32 bit version won’t work since Qubes-Whonix is 64 bit.)

I’ve reread this thread 5 times now. Still not clear to me. Could you please reiterate briefly what is broken in Qubes-Whonix-Workstation 13 with no AppArmor vs Qubes Debian based VM?

9

Ah - maybe that was the nightly was broken (not using the linux64-debug.zip).

Re: the standard “normal” 7.0a3, I think I manually installed it last time.

Anyway, this time I used Tor Browser Downloader by Whonix in a clean AppVM and downloads fine, sigs check out, and then when trying to extract it, this happened (twice):

Error: Could not extract /home/user/.cache/tb/files/tor-browser-linux64-7.0a3_en-US.tar.xz!

(Debugging information:
tar exit code: 1
pv_exit code: 0
tar_exit_code: 1
pv_wrapper_exit_code: 0)

Please report this bug!

10

Disk full by chance? Can you check please df -h?

Could you manually verify the files please? All files are in this folder.

~/.cache/tb/

Just as if you downloaded it yourself. And manually extract?

1 Like
11

OK - solved it. (you can mark this thread as “solved”)

1) That extraction error above refers to a full anon-whonix AppVM that doesn’t have enough room to extract the tar file, as you pointed out. :slight_smile:

Deleting a load of old-tor-browser directories under the .tb folder solves that problem (edit: correction - increasing the private storage size for the AppVM). We should note somewhere in the docs that if Qubes-Whonix users get that message, they need to delete old tor-browser folders, or the new Tor Browser file won’t extract.

2) With Whonix Downloader, Tor Browser 7.0a3 works flawlessly in Qubes-Whonix. I must have stuffed up something before.

I could even run it in high security slider mode and play Youtube as well as basic online gaming etc. Everything works and didn’t crash once in this mode.

Great.

3) With Apparmor profiles enforced, it is completely unusable, with the error messages I already outlined above. So, I’ll take those and dump them in the Apparmor Forum where they belong.

Cheers!

1 Like
12

Great!

If you like to test “even more alpha”, i.e. nightly versions, you are most welcome to, since probably no one else is doing it. The earlier we can notice any Whonix specific breakage, the better the chances to get it reported and fixed before that version gets the alpha or even stable.

All Whonix users.

For reference:

1 Like
13

Actually, I realized I had to increase the size of the private storage for the AppVM to extract that file (forgot I did that first).

I noticed that after deleting old tor-browser folders (emptying into trash), if the AppVM is restarted - bam - they’re back!

Weird, what gives? Clearly the .tb folder is under user/home, so while this is a persistent area in Qubes, it shouldn’t keep copies of stuff the user has explicitly deleted?

Same thing happens if you use the rm -rf command from the command line, they keep coming back, like Jason from Friday the 13th.

In fact, this is a security issue i.e. user AppVM gets hacked, and now the attacker has access to every old tor-browser version ever used, and presumably user data that lies around inside them in various files.

Also, when you create a new AppVM based on the TemplateVM, sure enough there’s multiple old versions of the tor-browser folder hanging around (test it for yourself). Shouldn’t this be clean to start with?

When you check the Workstation TemplateVM, the folders aren’t there (as expected), so this is not a template issue.

I’ve check the Qubes docs, and don’t see anything about it, except for checking from dom0 if your entire HDD/SDD is full, and how to deal with it (which mine is nowhere near being full).

15

Likely related to this mechanism:

If that is the case then it would just be a disk space issue. Fresh
unused copies from /var/cache/tb-binary/.tb/ would be copied. That
would not be a local data privacy issue.

Please run and post the output here:

ls -la /var/cache/tb-binary/.tb/

And:

ls -la /var/cache/tb-binary/.cache/tb/files/
1 Like
16

OK - thanks. Definitely related to ⚓ T417 up to date versions of Tor Browsers in newly created AppVMs inherited from updated TemplateVMs

I can see 6 x “tor-browser-old” versions in the cache + current version in use. .cache/tb/files just shows sha256sums.txt and sha256sums.txt.asc

Re: the “usability impact” noted in that closed phabricator ticket, I think it is true that most users will keep:

… use a single Qubes-Whonix-Workstation TemplateBased AppVM and sticking with it for a long time.

So, the effectively means that after 5-6 tor browser updates using Whonix downloader, they will hit the (somewhat cryptic) extraction error I did.

Of course, I hit this due to playing with Qubes-Whonix versions lately to get ESR52 working. But still, it means some 30 weeks later or so (6 week release cycle for Tor Browsers [using the Whonix downloader method] x 5 updates), users will run out of room in their standard AppVM which is set to around 2GB.

Manual solution:

Safe to delete old versions from Whonix-Workstation TemplateVM cache folder by hand?

Auto solution:

Can tb-updater be configured to detect more than one “tor-browser.old.XXXX” version in /var/cache/tb-binary/.tb and auto-delete for the user?

That is, just keep one old version in the cache, so that should the user hit problems with the current release (for whatever reason), they can use the old one as a very short term interim solution?

17

Yes.

I thought about this before. Old copies of Tor Browser accumulate over time. Not a big issue in case of Non-Qubes-Whonix. But Qubes-Whonix default TemplateVM root image size is small in comparison.

The user might have customized Tor Browser in Whonix-Workstation TemplateVM. By auto deleting the old folder, data could be lost. I don’t know how to solve this. //cc @marmarek

18

Created a ticket for it.

old Tor Browser versions in /var/cache/tb-binary/.tb/ accumulate in Qubes-Whonix, users run into full up disk error issues
https://phabricator.whonix.org/T671

1 Like
19

How difficult is it to detect user customization? Like compare some hash
with known unmodified version? If it’s easy, then simply delete if not
modified. But still customized case needs to be handled somehow. What
about keeping last 3 copies (or so)? If user wasn’t interested in older
copies (and haven’t migrated settings to newer version), probably won’t
be anytime later. Of course this need to be communicated to the user
somehow - a README file in that directory?

1 Like
20

Sounds good. Should checksum the folder from now. Not super straight forward (no tool for that), but very much doable. (File modifications and new files should matter most for comparision. File permission changes only should be super rare to non-existing cases.)

Should also add a free disk space check and show a warning if there is little disk space.

And add a recommendation to delete old folders there are more than three of them.