Using Whonix-Workstation as a DisposableVM (DispVM)

###This thread is now deprecated in favor of the wiki entry:



Just starting a topic to share tips and ask for help. And gather items to add to the wiki.

Create: Qubes Disposables
Customize: Redirecting…
Use: Redirecting…

Motivation: Since Tor Browser doesn’t save history anyway, there’s no reason to expose the rest of your Workstation to the Internet. Ideally, all browsing should be done in DispVMs. Exceptions, if any, should only be made for trusted, bookmarked, white-listed sites.

  • DispVMs are assigned their own IP address - meaning all of their traffic is stream isolated from your other Workstations.
  • Qubes secure clipboard and secure file copy make it easy to exchange information with a DispVM.

Until this ticket is solved (planned for Qubes 4.0), here’s the non-user-friendly method to add DispVM shortcuts to the application menu:

Warning: A Whonix-Workstation based custom Disposable VM must be created first using the steps above. Otherwise, these commands will generate a DispVM based on the default Fedora DispVM Template.
Warning2: Check netVM. (Already in the wiki.)

  1. Right-click Application Launcher Menu
  2. Select Edit Applications...
  3. Select DisposableVM fromVM entries on the left panel
  4. Click New Item on the Toolbar
  5. Type in a Name for the shortcut
  6. Example Commands:
    Tor Browser
    sh -c 'echo torbrowser | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'
    sh -c 'echo /home/user/.tb/tor-browser/Browser/start-tor-browser | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'
    Konsole
    sh -c 'echo konsole | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'
    Dolphin
    sh -c 'echo dolphin | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'
  7. Click on the square in the upper right if you’d like to choose an icon
    (Custom application icons are stored in /var/lib/qubes/<type of vm>/<vm name>/apps.icons/)
  8. Click Save

This is a major upgrade! Thanks Whonix team!

2 Likes

Is your DVM template based on whonix-ws? If not, doesn’t this method (which is the method I used with TorVM for years before switching to Qubes-Whonix) mean that your DispVM will be based on the default template (e.g., fedora-23)?

Yes. Prior version (Whonix-12) had issues being used as a DVM template.

Not sure what you’re referring to… The menu shortcuts? According to Qubes Docs, “Note that currently Qubes supports exactly one DispVM template, so any changes you make here will affect all DispVMs.” The same shortcuts call whonix-dvm when that is the only configured dvm-template. (From the current active thread on qubes-devel, looks like this will all change in Qubes4).

(As a side benefit, no more need for my fedora-23 template and its fat (firefox, icedove, etc.) Switched to fedora-23-minimal for ServiceVMs (sys-net, sys-usb, etc) and everything else is whonix.)

(Axon: Looking forward to 3.2 and a Qubes Forum. Isn’t this nice and cozy over here?)

If your DVM template were based on a non-whonix-ws template (which it’s not), then your DispVMs would not be based on whonix-gw. That’s all.

(Is it possible that you missed the bolded part?)


Indeed, it is very nice, but discussions about a Qubes forum are still ongoing.

Yes! Pardon my semi-literacy. I see your point now. As a Warning: whonix-ws based dispVM must be setup prior to issuing these commands or you will launch the default fedora dispVM! (And it may or may not be using whonix-gw as netVM). Being able to explicitly call a whonix-ws dispVM would be a much safer option. (As would being able to define the --default-[DVM]template.)

1 Like

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

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

No.

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

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

1 Like

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.

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

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

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

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

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:]

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.

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.

When DispVM template is created

I guess you meant whonix-ws.

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