Some really great progress wrt bubblewrap in Qubes in the ticket.
breaks with /proc/xen mounted (QubesOS) · Issue #134 · containers/bubblewrap · GitHub
1 Like
To translate it, I think the following is the only additional command one has to run before being able to run bubblewraped Tor Browser in Qubes.
sudo umount /proc/xen
1 Like
That’s great!
So, can Qubes-Whonix users just follow the instructions here:
with an additional step of:
sudo umount /proc/xen
before launching with:
./sandboxed-tor-browser
?
Let me know, and I can trial this for you ASAP, as I’m dying to run this sandbox in Qubes. I’d love to also run it in a Whonix-WS dispVM successfully. I can also check the dependencies stuff at the same time.
PS I’m holding off on grsec testing on Whonix templates, as Coldhak is definitely working on it currently. So there is some reason why it is separate work, otherwise they would have recommended the same steps as per the Debian-8 Template. Unless you have it working already in your set-up?
Debian-8 coldkernel is running like a dream though. Very stable.
Yes, please try.
If it works great in Qubes Debian 8 template, it very much should so so in Qubes-Whonix due to no differences in kernel. At most apparmor might no longer load. Dunno. Haven’t gotten around to testing it yet.
I wonder if bubblewrap will work in combination with grsecurity. Please try.
(Answered in chronological order.)
In the non-Qubes-Whonix guide for sandboxing, we have instructed to download the 64-bit version of the alpha sandbox by mistake?
Or is this okay, because the templates are updated to the ‘Whonix-14’ in progress? If it does need to change, then I’ll edit as follows.
Step 1 of the Download would need to point to instead:
wget https://www.torproject.org/dist/torbrowser/6.5a6/sandbox-0.0.2-linux32.zip
wget https://www.torproject.org/dist/torbrowser/6.5a6/sandbox-0.0.2-linux32.zip.asc
And this part of step 2 changed to:
gpg --verify sandbox-0.0.2-linux32.zip
Let me know.
Once Whonix 14 is released, these instructions for non-Qubes-Whonix need to be edited to remove reference to ‘updating to Whonix work in progress’. Might be worth noting on phabricator somewhere, as I know you have a high priority item for this.
1 Like
Just checking in here:
- Can we expect that updating to Whonix-14 in progress also sets everything to Debian Stretch in the templates?
- We should accept any updated installer scripts for swdate and pulse (maybe not the latter) when doing the full upgrade then to Stretch?
- Checks for the updated control-port-filter in the wiki e.g. nc commands, are only for non-Qubes-Whonix and not Qubes-Whonix I believe?
- Proper sys-whonix technique in Qubes for testing updated (Whonix-14 GW) is to simply change the template over in Qubes settings OR create an alternative sys-whonix so networking isn’t completely (potentially) borked?
Anyhow, to date my updated ‘sandboxed’ WS and GW templates segfault when I try to open Konsole with some vague library libkdeul.so, after full Whonix-14 developers and Debian Stretch updates, so they seem to be broken.
I don’t have any issues with a Debian-9 template updated using Qubes recommended method, so I’ll just test first if sandboxed Tor Browser running off that will work i.e. starting with a simple platform first.
This should at least answer the issue around current compatibility of Qubes kernels and whether bubblewrap issues are sorted, plus required dependencies i.e. only starting with bubblewrap and moving up from there until the thing actually starts.
PS Those ‘additional dependencies’ gnome-themes-standard gnome-themes-standard-data are already installed in the upgraded templates, so that step is apparently not needed for Qubes-Whonix.
I also fixed the wiki entry which was referring to unzipping an .asc file, instead of the .zip file.
One step forward, three steps back 
1 Like
I guess so.
It didn’t when we discussed this last time. But at the current state of the developers repository it is required to upgrade to stretch as per these instructions:
The developers repository currently is in a broken state. Getting the upgrade through requires some apt-get / dpkg gymnastics, control-port-filter-python does not work for some reason and networking is broken in the workstation (we might have to port form ifupdown to systemd-networkd). I can notify you once the developers repository is back to a working state and/or when there will be Whonix 14 developers-only downloadabe images.
I don’t know what you mean by that.
For Qubes-Whonix only the IP would be different. The IP of eth1. The checks won’t be required for anything near release.
In fact I have whonix-gw / whonix-ws templates based on Whonix stable-proposed-updates. Then cloned these templates. Made them whonix-gw-dev / whonix-ws-dev. And the derivative template based VMs sys-whonix-dev / anon-whonix-dev. If something goes wrong, I can still use the stable ones.
Fixed in wiki to 32bit.
Ah - that makes sense now why it broke. Please do notify on this thread when the depository is working and/or Whonix 14 images are available for download.
I mean during a full update of a template, we accept any changes when the a message pops up like e.g:
“Setting up ifupdown …
Configuration file `/etc/network/interfaces’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** interfaces (Y/I/N/O/D/Z) [default=N] ? N”
OK - good to know.
Thanks. It’s good to know the ‘safe’ method, and this will form part of the wiki entry later on, so people aren’t left with broken networking when attempting alpha instructions.
1 Like
Yes. Whonix 14 is really not ready. Not even for testers. So sandboxes
Tor Browser has to wait unfortunately.
Feedback.
Testing on Debian-8 and pointing to system tor (sys-whonix), sandboxed-tor-browser and the extra step of sudo umount /proc/xen successfully:
- detects system tor process;
- downloads Tor; and
- verifies it correctly.
The mounting error message disappears, but we now run into:
launch: Connecting to the Tor network.
tor: setsid
tor: : Function not implemented
launch: Failing with error: tor: timeout waiting for the control port
The same problem occurs if using sandboxed-tor-browser by just pointing to sys-firewall as the netVM in the system instead. Not clear why, since the bundle ‘should just work’ in that instance right?
By the way, this is with the only dependency installed being bubblewrap and nothing else.
So, we can remove golang, libseccomp2 and libseccomp-dev dependences from the wiki. Also, gnome-themes-standard and gnome-themes-standard-data seem to be already installed on both the Debian and Whonix templates, so that step can be removed too.
I wonder whether a Whonix-WS Template could have just the control-port-filter-python package installed and not the whole Whonix-14 upgrade as an intermediate try? Probably not i.e. depending on a host of other things already broken.
Let me know if there’s anything else I should try.
1 Like
Unfortunately backporting that package to Whonix 13 is not so simple, because multiple components are involved. (Also whonix-gw-firewall, anon-gw-anonymiznizer-config…)
Works for me in Qubes Debian based VM.
Remove eventually old copies of it.
(I prefer using trash-put because if you are using rm and mess up adding a space ~/ sandbox then you end up deleting your whole home folder.)
trash-put ~/sandbox
trash-put ~/.local/share/sandboxed-tor-browser
Trying to upgrade the old version failed for me.
2017/01/25 10:19:34 launch: Failing with error: dynlib: Failed to find library: libasan.so.2
Didn’t investigate since starting to use the new version worked for me.
For your convenience:
wget https://dist.torproject.org/torbrowser/7.0a1/sandbox-0.0.3-linux64.zipwget https://dist.torproject.org/torbrowser/7.0a1/sandbox-0.0.3-linux64.zip.ascgpg --recv-keys "EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290"gpg --verify sandbox-0.0.3-linux64.zip.ascunzip sandbox-0.0.3-linux64.zip
Don’t forget the Qubes workaround.
sudo umount /prox/xen
Start.
cd sandbox
./sandboxed-tor-browser
Works also in the development version of Whonix on my disk so chances are very good this will work in Whonix 14.
Nice! I’ll have to test v0.0.3 in a Debian template soon.
Of course, mine will be the ‘dummy’ test, since I am no developer… 
1 Like
I updated the instructions regarding dependencies, 64-bit version etc which is awaiting sign-off here:
http://kkkkkkkkkk63ava6.onion/wiki/Tor_Browser#Tor_Browser_Sandboxed
This may or may not be relevant i.e. new config settings (?):
Sec. “Using a system-installed Tor process with Tor Browser” in start-tor-browser needs update
1 Like
I guess it will work. anon-ws-disable-stacked-tor supports almost any Tor configuration system Tor or TBB Tor. Due to time restraints, I can only test this once the next release is out. (The only thing that won’t work is writing to /etc/tor/torrc or TBB torrc.) Applying the patch manually / building oneself is very time intensive.
Bad news. Quote:
- Linux · Wiki · The Tor Project / Applications / Tor Browser · GitLab
- Linux · Wiki · The Tor Project / Applications / Tor Browser · GitLab
WARNING: Active development is on indefinite hiatus. DO NOT EXPECT ANY SIGNIFICANT NEW FEATURES OR IMPROVEMENTS.