diff --git a/docs/common-tasks/opening-links-in-other-vms.md b/docs/common-tasks/opening-urls-in-vms.md similarity index 52% rename from docs/common-tasks/opening-links-in-other-vms.md rename to docs/common-tasks/opening-urls-in-vms.md index a196f6c..da2ea52 100644 --- a/docs/common-tasks/opening-links-in-other-vms.md +++ b/docs/common-tasks/opening-urls-in-vms.md @@ -1,15 +1,18 @@ How to open links/files in other VMs ==================================== -This document describes how to automatically open files/attachments or URLs from a VM in another VM (usually a dispVM), with or without user confirmation. This setup particularly suits "locked down" VMs with restrictive firewalls like "mailVMs". +This document shows how to automatically open files/attachments/URLs in another VM, with or without user confirmation. This setup particularly suits "locked down" setups with restrictive firewalls like VMs dedicated to emails. -Naming convention: `srcVM` is the VM where the files/URLs are, while `dstVM` is the VM we want to open them in. `dstVM` can be any VM type - a dispVM, a regular AppVM, a whonix dvm, ... +Naming convention: + +- `srcVM` is the VM where the files/URLs are +- `dstVM` is the VM we want to open them in ; `dstVM` can be any VM type - a DispVM, a regular AppVM, a Whonix dvm, ... Configuring `srcVM` ------------------- -There are a few approaches that one can follow to open files as we'll see below, but all of them rely on the `qubes.OpenInVM` and `qubes.OpenURL` [RPC services](https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-services), usually through the `qvm-open-in-vm` and `qvm-open-in-dvm` scripts. +There are quite a few approaches that one can choose to open files, each with their pros and cons. However the mechanism is the same for all of them: they use the `qubes.OpenInVM` and `qubes.OpenURL` [RPC services](https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-services) (usually through the use of the `qvm-open-in-vm` and `qvm-open-in-dvm` scripts). ### Command-line ### @@ -28,17 +31,17 @@ qvm-open-in-dvm http://example.com qvm-open-in-dvm word.doc ~~~ -(Actually `qvm-open-in-dvm` is a wrapper to `qvm-open-in-vm`). +Note: `qvm-open-in-dvm` is actually a wrapper to `qvm-open-in-vm`. ### Per application setup ### -Stepping up from the command line approach, a better solution would be to configure each application to use the `qvm-open-in-vm` script. +Stepping up from the command line approach, a better solution would be to configure each application to use the `qvm-open-in-{vm,dvm}` scripts. #### Thunderbird #### -In the case of Thunderbird, that would mean defining actions for attachement (see the [mozilla doc](http://kb.mozillazine.org/Actions_for_attachment_file_types), mainly section "Download Actions" settings"). Changing the way http and https URLs are opened requires tweaking config options (see [this mozilla doc](http://kb.mozillazine.org/Changing_the_web_browser_invoked_by_Thunderbird)). This can be made with thunderbird's config editor, or by adding the following to `$HOME/.thunderbird/user.js`: +In the case of Thunderbird, one has to define actions for opening attachements (see the [mozilla doc](http://kb.mozillazine.org/Actions_for_attachment_file_types), mainly section "Download Actions" settings"). Changing the way http and https URLs are opened requires tweaking config options though (see [this mozilla doc](http://kb.mozillazine.org/Changing_the_web_browser_invoked_by_Thunderbird)). Those changes can be made in Thunderbird's config editor, or by adding the following to `$HOME/.thunderbird/user.js` like so: ~~~ user_pref("network.protocol-handler.warn-external.http", true); @@ -47,29 +50,31 @@ user_pref("network.protocol-handler.warn-external.https", true); user_pref("network.protocol-handler.expose-all", true); ~~~ -The next time you click on a link, Thunderbird will ask which program to use. If you want to open links in dispVMs, choose `qvm-open-in-dvm`. Otherwise you'll have to create a wrapper since you can't pass arguments in Thunderbird's dialog. For instance, put the following in `$HOME/bin/thunderbird-url`, make it executable, and choose that script for opening http/https URLs: +Thunderbird will then ask which program to use the next time a link is opened. If `dstVM` should be a regular dispVM, choose `qvm-open-in-dvm`. Otherwise you'll have to create a wrapper since arguments cannot be passed to the program in Thunderbird's dialog. For instance, put the following in `$HOME/bin/thunderbird-url`, make it executable, and choose that script: ~~~ #!/bin/sh qvm-open-in-vm dstVM "$@" ~~~ + #### Firefox, Chrome/Chromium #### -Those programs probably have the same mechanism as Thunderbird to define what program to use for each file (Mime) type. However this isn't really flexible - one may want to open files in different dstVMs depending on the site's level of trust - in which case Raffaele Florio's [qubes-url-redirector](https://github.com/raffaeleflorio/qubes-url-redirector) add-on comes handy: links can be opened with context menu entries, the add-on has a settings page embedded in browser to customize default behavior, with support for whitelist regexes). +Like Thunderbird those programs offer an option to define programs associated to a file (Mime) type. However this isn't really flexible - eg. one may want to open files in different dstVMs depending on the site's level of trust - in which case Raffaele Florio's [qubes-url-redirector](https://github.com/raffaeleflorio/qubes-url-redirector) add-on comes handy: links can be opened with a context menu and the add-on has a settings page embedded in the browser to customize itsdefault behavior, with support for whitelist regexes. #### Vi #### -Put the following in `$HOME/.vimrc` to open URLs in `dstVM` with `gx` when the cursor is over an URL: +Put the following in `$HOME/.vimrc` to open URLs in `dstVM` (type `gx` when the cursor is over an URL): ~~~ let g:netrw_browsex_viewer = 'qvm-open-in-vm dstVM' ~~~ + ### Application independent setup ### -The approach above relied on configuring *each* application; it's the most flexible approach but is overkill and time consuming when the same action/program should be used by all the applications in `srcVM`. +The section above relied on configuring *each* application; it is the most flexible approach but is overkill and time consuming when the same action/program should be used by all the applications in `srcVM`. Providing the applications adheres to the freedesktop standard, defining a global action is straightforward: @@ -103,16 +108,17 @@ When using `qvm-open-in-{vm,dvm}` scripts (`qubes.OpenInVM` and `qubes.OpenURL` "Named, semi-permanent" dispVMs ------------------------------- -Opening things in dispVMs is the most secure approach, but the long starting time of dispVMs often gets in the way so users end up opening files/URLs in persistent VMs. A middle-ground solution is to create a "semi-permanent" dispVM like so: +Opening things in dispVMs is the most secure approach, but the long starting time of dispVMs often gets in the way so users end up opening files/URLs in persistent VMs. An intermediate solution is to create a "semi-permanent" dispVM like so (replace `fedora-28-dvm` with the dvm template you want to use): ~~~ qvm-create -C DispVM -t fedora-28-dvm -l red dstVM ~~~ -This VM works like a regular VM, with the difference that its private disk is wiped after it's powered off. However it doesn't "auto power off" like random dispVMs, so it's up to the user to power off (and optionaly restart) the VM when he/she deems necessary. +This VM works like a regular VM, with the difference that its private disk is wiped after it's powered off. However it doesn't "auto power off" like random dispVMs so it's up to the user to power off (and optionaly restart) the VM when he/she deems necessary. Further considerations/caveats of dispVMs: -- Obviously, using dispVMs (whether random or "semi-permanent") for `dstVM` means that any change - saved bookmarks, application preferences, add-on update, ... - is lost at poweroff. Saving changes persistently requires updating the VM's templateVM. -- Bookmark management could be eased with tools like [buku](https://github.com/jarun/Buku) (available in Fedora 28 repo - `dnf install buku`). +- Obviously, using dispVMs (whether random or "semi-permanent") for `dstVM` means that any change - saved bookmarks, application preferences, add-on update, ... - is lost at poweroff. Saving changes persistently requires updating the VM's templateVM, which may be cumbersome. +- inter-VM bookmark management might be eased with tools like [buku](https://github.com/jarun/Buku) (available in Fedora 28 repo - `dnf install buku`). +