Using Whonix-Workstation as a DisposableVM (DispVM)

Qubes-Whonix
6

This is something too great to have it only in a forum post. I’d appreciate if you could add it to the wiki! (After sorting out my issue, of course. :))

I am lost at that step. There is no DisposableVM entry for me. And I have not figured out how I could create a new entry that is on the same level as the other domains. As a sub menu, this would work, I suppose.

sh -c 'echo /home/user/.tb/tor-browser/Browser/start-tor-browser | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'

Please edit and make that:

`sh -c ‘echo torbrowser | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red’``

It’s cleaner. Should work?

1 Like
7

Strange, it should be there as part of a default Qubes installation. Is one generated with qvm-create-default-dvm?

8

No.

9

Since I am lacking this… What is the command line tool to have the Qubes DVM Qubes start menu entry created? (I plan on running it to see if it outputs any errors.) //cc @marmarek

10

Could you add this please to the wiki? Usage instructions currently are not documented there. @entr0py

1 Like
11

Hi entr0py and Patrick,

This guide works fine up to the step of adding the menu items, due to the 3.2 version of Qubes shifting to XFCE as default. That is, there is no “Edit Applications…” option.

The guides on-line for manually editing XFCE menus are horrendous. Have you managed to add a Tor Browser menu entry under the disposable VM menu listing? If so, can you please share?

If not, should we just run Tor Browser from dispVM terminal? Can you post the necessary command? Thanks.

12

If you can launch a Whonix-Workstation dispVM terminal, you can also launch Tor Browser by using torbrowser command. Obviously, closing Tor Browser won’t destroy the dispVM - you’ll need to exit from Konsole to do that.

Ha! I just got done complaining about that…

I can’t try myself as I’m still on 3.1. I guess I’ll make the leap with Whonix 14. So keep in mind that I’m flying blind as I type the steps below and also this might not work at all.

  • First, make sure xfdesktop is installed. dnf list installed xfdesktop

  • You need to make .desktop files for every dispVM shortcut you want to add to your menus. (Manual: Desktop Entry Specification) They need to be put in ~/.local/share/applications/

  • For example: nano ~/.local/share/applications/dvm-torbrowser.desktop
    Add:

    [Desktop Entry]
    Name=Tor Browser
    Comment=Launch Tor Browser in Disposable VM
    Type=Application
    Terminal=false
    Exec=sh -c ‘echo torbrowser | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red’

You can play around with Icon=, Category=

  • To add the .desktop files to your menu, you need to: nano ~/.config/menus/xfce-applications.menu

  • Scroll down until you see:

    <Menu> <Name>DispVM-blah-blah</Name>

then in the <Include> section add:
<Filename>dvm-torbrowser.desktop</Filename>

That might work… maybe. (Shouldn’t need reboot.)

2 Likes
13

Actually, I find this to be a benefit and for any extended dispVM session, I’ll always launch Konsole first. I can’t tell you how many times I’ve downloaded files in TBB, launched Konsole to manipulate them, and then shut down TBB and lost everything. Now I open a Konsole and launch all my disposable programs from that. Then I know everything will persist until I exit Konsole.

2 Likes
14

How to Update Tor Browser in a (Customized) Whonix DisposableVM

tb-updater updates Whonix-Workstation TemplateVM (whonix-ws) local copy of TBB stored in /var/cache/tb-binary.
tb-updater does not update existing Tor Browser installations in appVMs or in the dispVM.

Assuming your dispVM is named whonix-ws-dvm:

  1. Make sure Qubes VM Manager > View > Show Internal VMs is checked.
  2. Right-click whonix-ws-dvm in Qubes VM Manager and select Run Command in VM
  3. Type torbrowser and click Ok
  4. Use Tor Browser’s Internal Updater by clicking TorButton and selecting Check for Tor Browser Update
  5. Restart and close Tor Browser
  6. Right-click whonix-ws-dvm and select Shutdown VM
  7. Regenerate dispVM image by running in dom0 terminal:
    qvm-create-default-dvm whonix-ws

[Is Tor Browser automatically installed when dispVM is created (as per new appVMs)? I can’t remember. If yes, then these instructions are only necessary for customized dispVMs. It’s much simpler to wait for tb-updater to update anon-whonix whonix-ws and then just create a fresh dispVM template every time there is a new TBB.]

1 Like
15

Thanks a lot entr0py, good information!

I’m sending this message from the Tor Browser 6.5.a5-hardened in a disposable VM. Two thumbs up. :+1:

LOL @ running torbrowser in the terminal. I imagined something complex i.e. terminal wizardy.

For login credentials stored in an off-line VM (like vault), do you store them with a password manager and then use secure cut and paste into Tor Browser? This does indeed seem much safer than typing passwords into Tor Browser because it avoids potential keylogging from an exploited session.

For the interest of other Qubes 3.2 users, I realized I could not get not get qvm-create-default-dvm to work off an existing whonix-ws appVM (normally labelled anon-whonix in the default arrangement, unless you’ve changed it manually).

dom0 keeps reporting “anon-whonix is not a directory”.

Since it works for entr0py in Qubes 3.1, maybe there has been some change? A little strange.

It was in fact very annoying, because using the normal whonix-ws TemplateVM always meant that the dispVM provided an outdated Tor Browser i.e. because it is the Tor Browser instance in whonix-ws AppVMs that are constantly updated by users (with internal updaters), and not the whonix-ws-templateVM version.

If you experience this same problem, the workaround is to:

  • run the Tor Browser updater in your whonix-ws-templateVM
  • download the latest Tor Browser with critical fixes from the last day or two
  • download version 6.0.7 if you want the stable version or 6.5.a5-hardened if you want the beast version
  • check the fingerprint matches Tor signing keys on torproject.org
  • install
  • then run in dom0: qvm-create-default-dvm whonix-ws

This will create a dispVM called whonix-ws-dvm (you can see it by selecting ‘Show/Hide internal vms’ under the Qubes VM manager View menu). Doublecheck the network VM is set to sys-whonix.

The problem with this method is that you will have to repeat this process every time a new TBB release comes out. Further, no bookmarks or other minor changes will be maintained e.g. add-on/search preferences.

I haven’t yet worked out the XFCE menus and how to add the Tor Browser entry (next project!), so in the meantime follow entropy’s advice above to run Tor Browser in a dispVM. That is:

  1. Run ‘xterm’ from the disposableVM menu under the Qubes VM Manager menu
  2. Then simply run the command: torbrowser
1 Like
16

Made same mistake - see strikethrough in OP. Embarrassing :wink:

I use keepassx to store credentials and urls too - the onion names are important to keep secure as well. It’s more out of habit and convenience though - not much gain in security over just using a plain text file in a vaultVM because dom0 compromise would be game over anyway.

In terms of keyloggers, any competent keylogger should be monitoring clipboard also so copy/pasting might not help that much. The original KeePass2 has auto-type obfuscation: Two-Channel Auto-Type Obfuscation - KeePass. That would help for limited observations. The real advantage to off-VM storage is limited exposure in case of compromise.

@rustybird mentions keepassx integration on his split-browser roadmap. That would be very useful. And it could be set to wipe the clipboard automatically after paste (tip from @patrick in hardening thread). (Does it do that already?)

That is correct. DispVMs must be based on templateVMs. I see my mistake - edited. Sorry.

Great, this answers my question:

So your instructions work fine. However, if we want to get nitpicky, that might not be considered canonical by Qubes devs. TemplateVMs should only have network connectivity via the update proxy. Whonix-Gateway provides general connectivity via Tor to all connected templateVMs because it uses it’s own non-standard firewall rules.

The way to install Tor Browser in your dispVM while keeping customizations and also maintaining templateVM sanctity(?) is to do the following:

  1. create the dispVM based on your whonix-ws template first:
    qvm-create-default-dvm whonix-ws
  2. enable show internal VMs in Qubes VM Manager
  3. confirm netVM for whonix-ws-dvm is set to sys-whonix
  4. launch terminal in whonix-ws-dvm by right-clicking in QubesVMM; or via qvm-run -a whonix-ws-dvm <konsole | gnome-terminal | xterm>
  5. in dvm terminal: touch /home/user/.qubes-dispvm-customized
  6. install tor browser via update-torbrowser or manually. Or if you’ve kept updating tbupdater via apt-get, you can just cp -r /var/cache/tb-binary/.tb /home/user/
  7. customize dispVM however you want.
  8. shutdown dispVM
  9. dom0: qvm-create-default-dvm whonix-ws
    All of your changes should persist.

[this will get written up this weekend! :cry:]

17

Great! Thanks for this information.

I figured the way I did it was incorrect, so I had cloned the Whonix-WS template first so I could ‘undo’ the damage of my hack and do it the correct way. :wink:

Might I suggest that your guide also add an optional step around ‘hard-coding’ the hardened-Tor Browser for future updates done via the Tor updater? That is, I noted that after WS templates were updated yesterday for 6.0.7, it automatically over-rides the alpha version I had manually downloaded.

I figure that if the hardcore Qubes-Whonix fans are going to bother with dispVMs in this manner, many will want the hardened browser by default.

I can’t remember seeing in the Whonix documentation where the ‘hard coding’ option is set, or how this is done.

18

Sure. You can cheat right now by going to GitHub - Kicksecure/tb-updater: Tor Browser Downloader - Automates download and verification of Tor Browser from The Tor Project's website. This package is produced independently of, and carries no guarantee from, The Tor Project. and looking at the latest commit. relevant setting is stored in /usr/share/tb-updater/tbb_hardcoded_version

Ok, this means that I jumped to wrong conclusion re:

So I checked and dispVM template is indeed treated as an appVM for qubes-vm-type purposes, which means that TBB is in fact installed by first-boot-home-population when a dispVM is first created. Which means that this comment from you doesn’t jive:

The whonix-ws version should be up-to-date (just a few days later) (with the stable TBB) (unless you disable tb-updater). Ok, now we’re on the same page.

And yes, to confirm your observation, if you manually install hardened TBB in whonix-ws template: /home/user/.tb/, then it will be overwritten when you create a new appVM or dispVM template, by whatever tb-updater has downloaded.

This also means that there are 2 methods to update Tor Browser in a Disposable VM:

  1. For a non-customized whonix-ws dispVM, the easiest method is to keep whonix-ws updated and qvm-create-default-dvm whonix-ws each time tb-updater package is updated.

  2. For a customized whonix-ws dispVM, follow the instructions above. Using Whonix-Workstation as a DisposableVM (DispVM) - #14 by entr0py

And, this also simplifies initial dispVM creation method:

(optional) 0. choose TBB version by editing hardcoded setting

  1. make sure whonix-ws is up-to-date by running apt-get.
  2. qvm-create-default-dvm whonix-ws
  3. show Internal VMs
  4. confirm netVM
  5. done. continue only if you want to customize the dispVM template
  6. steps #4-9 from my previous post, minus #6.

Ok, big mess here… time to update the wiki. The hardcoded stuff is probably going to go in a footnote - it’s confusing and not recommended.

@torjunkie when you have time, please let me know if the xfce instructions work.

19

When DispVM template is created

I guess you meant whonix-ws.

20

Please report a bug against Qubes.
Issues · QubesOS/qubes-issues · GitHub

I don’t recommending editing /usr/share/tb-updater/tbb_hardcoded_version since it will be overwritten on next update anyhow. If anything, use instead:

  • Whonxi 13: /etc/torbrowser.d/50_user.conf
  • Whonix 14: /etc/torbrowser.d/50_user.conf / /rw/config/torbrowser.d/50_user.conf

Also modifying tbb_hardcoded_version is not useful at all. If you want to manually set it to a fixed value you can use tbb_version which is designed to have priority over anything that tbb_hardcoded_version does. Example:

tbb_version="6.5a5-hardened"

Even manually setting tbb_version in config does not great since then one will keep that version forever (unless manually modified again) even when tbb_hardcoded_version is higher. So perhaps I should add a variable “tbb_use_this_version_if_higher_than_tbb_hardeced_version”? (Any variable name suggestions?)

Btw update-torbrowser can be used completely without user interaction. I.e. all question can be answered beforehand by setting the right variables. This is currently not documented and becomes only clear by reading the update-torbrrowser script code.

The automatic Tor Browser upgrade when the tb-updater package is upgraded can also be disabled. That is documented here:
Tor Browser Essentials

21

There are multiple layers of confusion here. It’s a mess from a users point of view.

  • Tor Browser updating / tb-updater is confusing (Tor Browser ought to be installed as a deb, then all confusion would vanish)
  • tb-updater interaction with Qubes TemplateVM vs AppVM is confusing - Tor Browser Essentials
  • Qubes “double layered” DispVM implementation is confusing

EDIT, added these two points:

And when you mix all of that together, we have the ultimate usability mess.

In Qubes 4.0 hopefully DispVM implementation will get a lot simpler. Then one can have multiple DispVMs easily. No more double layered template. No more savefile. For a TemplateBased AppVM then hopefully “persistent /home” will just be an enabled / disabled checkbox. At least that is what we agreed upon at 32c3 meeting.

https://forums.whonix.org/t/qubes-dispvm-technical-discussion

1 Like
22

You might be interested in this related tb-updater thread:

https://forums.whonix.org/t/tb-updater-experimental-alpha-beta-rc-hardened-options

23

See my comments and suggested wiki entries on Patrick’s thread above.

1 Like
24

For all of you who thought I would never write a page, wiki is hereby pending update: Qubes Disposables

#notvaporwiki

1 Like
25

'fraid to say this probably won’t happen anytime soon… KeePassX doesn’t expose any API that split-browser-login could use:

There is however a fork called KeePassXC that does:

But that would only be the interface between KeePassX(C) and split-browser-login, whereas split-browser-login would still communicate with the DisposableVM’s browser via fake keypresses.

2 Likes