From 9b69a5a1464b324b8be5e77ba67cee02bb157e1f Mon Sep 17 00:00:00 2001 From: Yethal Date: Fri, 10 Mar 2017 02:12:33 +0100 Subject: [PATCH 1/7] Cleaned up documentation Moved USB qube instructions to the top of the document. Removed references to closed out issues. Added USB mouse instructions. Added disk passphrase warning. Removed Qubes 3.1 specific references due to EOL. --- common-tasks/usb.md | 316 ++++++++++++++++++++++---------------------- 1 file changed, 155 insertions(+), 161 deletions(-) diff --git a/common-tasks/usb.md b/common-tasks/usb.md index fbaec8e9..736add68 100644 --- a/common-tasks/usb.md +++ b/common-tasks/usb.md @@ -17,6 +17,160 @@ redirect_from: Using and Managing USB Devices ============================== +Creating and Using a USB qube +----------------------------- + +The connection of an untrusted USB device to dom0 is a security risk since dom0, +like almost every OS, reads partition tables automatically and since the whole +USB stack is put to work to parse the data presented by the USB device in order +to determine if it is a USB mass storage device, to read its configuration, etc. +This happens even if the drive is then assigned and mounted in another qube. + +To avoid this risk, it is possible to prepare and utilize a USB qube. + +A USB qube acts as a secure handler for potentially malicious USB devices, +preventing them from coming into contact with dom0 (which could otherwise be +fatal to the security of the whole system). With a USB qube, every time you +connect an untrusted USB drive to a USB port managed by that USB controller, you +will have to attach it to the qube in which you wish to use it (if different +from the USB qube itself), either by using Qubes VM Manager or the command line +(see instructions above). +You can create a USB qube using the management stack by performing the following +steps as root in dom0: + + 1. Enable `sys-usb`: + + qubesctl top.enable qvm.sys-usb + + 2. Apply the configuration: + + qubesctl state.highstate + +Alternatively, you can create a USB qube manually as follows: + + 1. Read the [Assigning Devices] page to learn how to list and identify your + USB controllers. Carefully check whether you have a USB controller that + would be appropriate to assign to a USB qube. Note that it should be free + of input devices, programmable devices, and any other devices that must be + directly available to dom0. If you find a free controller, note its name + and proceed to step 2. + 2. Create a new qube. Give it an appropriate name and color label + (recommended: `sys-usb`, red). If you need to attach a networking device, + it might make sense to create a NetVM. If not, an AppVM might make more + sense. (The default `sys-usb` is a NetVM.) + 3. In the qube's settings, go to the "Devices" tab. Find the USB controller + that you identified in step 1 in the "Available" list. Move it to the + "Selected" list. + + **Caution:** By assigning a USB controller to a USB qube, it will no longer + be available to dom0. This can make your system unusable if, for example, + you have only one USB controller, and you are running Qubes off of a USB + drive. + + 4. Click "OK." Restart the qube. + 5. Recommended: Check the box on the "Basic" tab which says "Start VM + automatically on boot." (This will help to mitigate attacks in which + someone forces your system to reboot, then plugs in a malicious USB + device.) + +If the USB qube will not start, see [here][faq-usbvm]. + +How to hide all USB controllers from dom0 +----------------------------------------- + +If you create a USB qube manually, there will be a brief period of time during the +boot process during which dom0 will be exposed to your USB controllers (and any +attached devices). This is a potential security risk, since even brief exposure +to a malicious USB device could result in dom0 being compromised. There are two +approaches to this problem: + +1. Physically disconnect all USB devices whenever you reboot the host. +2. Hide (i.e., blacklist) all USB controllers from dom0. + +**Warning:** If you use a USB [AEM] device, do not use the second option. Using +a USB AEM device requires dom0 to have access to the USB controller to which +your USB AEM device is attached. If dom0 cannot read your USB AEM device, AEM +will hang. + +The procedure to hide all USB controllers from dom0 is as follows: + +1. Open the file `/etc/default/grub` in dom0. +2. Find the line that begins with `GRUB_CMDLINE_LINUX`. +3. Add `rd.qubes.hide_all_usb` to that line. +4. Save and close the file. +5. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. +6. Reboot. + +(Note: Beginning with R3.2, `rd.qubes.hide_all_usb` is set automatically if you +opt to create a USB qube during installation. This also occurs automatically if +you choose to [create a USB qube] using the `qubesctl` method, which is the +first pair of steps in the linked section.) + +**Warning** USB keyboard cannot be used to type the disk passphrase +if USB controllers were hidden from dom0 as USB qube is not active yet. Before hiding +USB controllers make sure your laptop keyboard is not internally connected via USB +(by checking output of `lsusb` command) or that you have a PS/2 keyboard at hand +(if using a desktop PC). Failure to do so will render your system unusable. + + +Removing a USB qube +------------------- + +**Warning:** This procedure will result in your USB controller(s) being attached +directly to dom0. + +1. Shut down the USB qube. +2. In Qubes Manager, right-click on the USB qube and select "Remove VM." +3. Open the file `/etc/default/grub` in dom0. +4. Find the line(s) that begins with `GRUB_CMDLINE_LINUX`. +5. If `rd.qubes.hide_all_usb` appears anywhere in those lines, remove it. +6. Save and close the file. +7. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. +8. Reboot. + +How to use a USB keyboard +------------------------- + +In order to use a USB keyboard, you must first attach it to a USB qube, then +give that qube permission to pass keyboard input to dom0. Note that allowing +keyboard access from a USB qube gives it great power. In short: + + * It will see whatever you type on that keyboard (including passwords). + * It will be able to inject keystrokes, which basically means that it will be + able to enter any command. For example, if some malware catches your + screenlocker password, it will be able to unlock the screen when you are not + present. (For more details, see [here][input-proxy].) + +If you are sure you wish to proceed, then you must edit the +`qubes.InputKeyboard` policy file in dom0, which is located here: + + /etc/qubes-rpc/policy/qubes.InputKeyboard + +Add a line like this one to the top of the file: + + sys-usb dom0 ask,user=root + +(Change `sys-usb` to your desired USB qube.) + +You can now use your USB keyboard. + +How to use a USB mouse +---------------------- + +In order to use a USB mouse, you must first attach it to a USB qube, then +give that qube permission to pass mouse input to dom0. +Edit the `qubes.InputMouse` policy file in dom0, which is located here: + + /etc/qubes-rpc/policy/qubes.InputMouse + +Add a line like this to the op of the file: + + sys-usb dom0 ask,user=root + +(Change `sys-usb` to your desired USB qube.) + +You can now use your USB mouse. + How to attach USB drives ------------------------ @@ -102,11 +256,7 @@ follows: Otherwise, you will not be able to attach it anywhere later. See issue [1082] for details. -There have been reports that when attaching a single partition, the Nautilus -file manager would not see it and automatically mount it (see issue [623]). -This problem seems to be resolved (see [this comment on issue 1072][1072-comm1]). - -If, however, the device does not appear in Nautilus, you will need to mount it +If the device does not appear in Nautilus, you will need to mount it manually. The device will show up as `/dev/xvdi` (or `/dev/xvdj` if there is already one device attached -- if two, `/dev/xvdk`, and so on). @@ -147,162 +297,6 @@ steps: `qvm-block -d` command. -Creating and Using a USB qube ------------------------------ - -The connection of an untrusted USB device to dom0 is a security risk since dom0, -like almost every OS, reads partition tables automatically and since the whole -USB stack is put to work to parse the data presented by the USB device in order -to determine if it is a USB mass storage device, to read its configuration, etc. -This happens even if the drive is then assigned and mounted in another qube. - -To avoid this risk, it is possible to prepare and utilize a USB qube. - -For this reason, you may wish to avoid using a USB qube if you do not have a USB -controller free of input devices and programmable devices, although Qubes R3.1 -introduced support for USB mice and keyboards (see below). - -A USB qube acts as a secure handler for potentially malicious USB devices, -preventing them from coming into contact with dom0 (which could otherwise be -fatal to the security of the whole system). With a USB qube, every time you -connect an untrusted USB drive to a USB port managed by that USB controller, you -will have to attach it to the qube in which you wish to use it (if different -from the USB qube itself), either by using Qubes VM Manager or the command line -(see instructions above). Again, this works only for USB mass storage devices. -Other devices cannot currently be virtualized. - -You can create a USB qube using the management stack by performing the following -steps as root in dom0: - - 1. Enable `sys-usb`: - - qubesctl top.enable qvm.sys-usb - - 2. Apply the configuration: - - qubesctl state.highstate - -(Note: This automatically [hides all USB controllers from dom0][hide-usb].) - -Alternatively, you can create a USB qube manually as follows: - - 1. Read the [Assigning Devices] page to learn how to list and identify your - USB controllers. Carefully check whether you have a USB controller that - would be appropriate to assign to a USB qube. Note that it should be free - of input devices, programmable devices, and any other devices that must be - directly available to dom0. If you find a free controller, note its name - and proceed to step 2. - 2. Create a new qube. Give it an appropriate name and color label - (recommended: `sys-usb`, red). If you need to attach a networking device, - it might make sense to create a NetVM. If not, an AppVM might make more - sense. (The default `sys-usb` is a NetVM.) - 3. In the qube's settings, go to the "Devices" tab. Find the USB controller - that you identified in step 1 in the "Available" list. Move it to the - "Selected" list. - - **Caution:** By assigning a USB controller to a USB qube, it will no longer - be available to dom0. This can make your system unusable if, for example, - you have only one USB controller, and you are running Qubes off of a USB - drive. - - 4. Click "OK." Restart the qube. - 5. Recommended: Check the box on the "Basic" tab which says "Start VM - automatically on boot." (This will help to mitigate attacks in which - someone forces your system to reboot, then plugs in a malicious USB - device.) - -If the USB qube will not start, see [here][faq-usbvm]. - - -Removing a USB qube -------------------- - -**Warning:** This procedure will result in your USB controller(s) being attached -directly to dom0. - -1. Shut down the USB qube. -2. In Qubes Manager, right-click on the USB qube and select "Remove VM." -3. Open the file `/etc/default/grub` in dom0. -4. Find the line(s) that begins with `GRUB_CMDLINE_LINUX`. -5. If `rd.qubes.hide_all_usb` appears anywhere in those lines, remove it. -6. Save and close the file. -7. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. -8. Reboot. - - -How to hide all USB controllers from dom0 ------------------------------------------ - -Even if you create a USB qube, there will be a brief period of time during the -boot process during which dom0 will be exposed to your USB controllers (and any -attached devices). This is a potential security risk, since even brief exposure -to a malicious USB device could result in dom0 being compromised. There are two -approaches to this problem: - -1. Physically disconnect all USB devices whenever you reboot the host. -2. Hide (i.e., blacklist) all USB controllers from dom0. - -**Warning:** If you use a USB [AEM] device, do not use the second option. Using -a USB AEM device requires dom0 to have access to the USB controller to which -your USB AEM device is attached. If dom0 cannot read your USB AEM device, AEM -will hang. - -The procedure to hide all USB controllers from dom0 is as follows: - -1. Open the file `/etc/default/grub` in dom0. -2. Find the line that begins with `GRUB_CMDLINE_LINUX`. -3. Add `rd.qubes.hide_all_usb` to that line. -4. Save and close the file. -5. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. -6. Reboot. - -(Note: Beginning with R3.2, `rd.qubes.hide_all_usb` is set automatically if you -opt to create a USB qube during installation. This also occurs automatically if -you choose to [create a USB qube] using the `qubesctl` method, which is the -first pair of steps in the linked section.) - -Supported USB device types --------------------------- - -As of Qubes R3.1, it is possible to attach: - - * USB mice - * USB keyboards (see below) - * USB block devices (such as USB mass storage devices) - * When attaching one of these, you should get a notification about the - new device, then you should be able to attach it to a qube in Qubes VM - Manager. - -Other devices, such as USB webcams, will also work, but they will be -accessible only from the USB qube itself, as explained above. - - -How to use a USB keyboard -------------------------- - -In order to use a USB keyboard, you must first attach it to a USB qube, then -give that qube permission to pass keyboard input to dom0. Note that allowing -keyboard access from a USB qube gives it great power. In short: - - * It will see whatever you type on that keyboard (including passwords). - * It will be able to inject keystrokes, which basically means that it will be - able to enter any command. For example, if some malware catches your - screenlocker password, it will be able to unlock the screen when you are not - present. (For more details, see [here][input-proxy].) - -If you are sure you wish to proceed, then you must edit the -`qubes.InputKeyboard` policy file in dom0, which is located here: - - /etc/qubes-rpc/policy/qubes.InputKeyboard - -Add a line like this one to the top of the file: - - sys-usb dom0 ask,user=root - -(Change `sys-usb` to your desired USB qube.) - -You can now use your USB keyboard. - Attaching a single USB device to a qube (USB passthrough) --------------------------------------------------------- From 2789a7064949abd454d1026b5e0eb9ea0e7f009d Mon Sep 17 00:00:00 2001 From: Yethal Date: Fri, 10 Mar 2017 02:14:57 +0100 Subject: [PATCH 2/7] Update usb.md --- common-tasks/usb.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common-tasks/usb.md b/common-tasks/usb.md index 736add68..ce83222f 100644 --- a/common-tasks/usb.md +++ b/common-tasks/usb.md @@ -107,8 +107,8 @@ you choose to [create a USB qube] using the `qubesctl` method, which is the first pair of steps in the linked section.) **Warning** USB keyboard cannot be used to type the disk passphrase -if USB controllers were hidden from dom0 as USB qube is not active yet. Before hiding -USB controllers make sure your laptop keyboard is not internally connected via USB +if USB controllers were hidden from dom0. Before hiding USB controllers +make sure your laptop keyboard is not internally connected via USB (by checking output of `lsusb` command) or that you have a PS/2 keyboard at hand (if using a desktop PC). Failure to do so will render your system unusable. From e0bc95ff02245fed206ba4d46965419e19599c07 Mon Sep 17 00:00:00 2001 From: Yethal Date: Sat, 11 Mar 2017 23:20:21 +0100 Subject: [PATCH 3/7] Update dispvm.md Added Applications Menu instructions --- common-tasks/dispvm.md | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/common-tasks/dispvm.md b/common-tasks/dispvm.md index 1f5af78c..3914eba3 100644 --- a/common-tasks/dispvm.md +++ b/common-tasks/dispvm.md @@ -45,8 +45,7 @@ Use the `qvm-open-in-dvm` command line (from your AppVM), e.g.: [user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf ~~~ -The qvm-open-in-dvm will not exit until you close the application in the Disposable VM. - +The qvm-open-in-dvm will not exit until you close the application in the Disposable V Starting an arbitrary application in a disposable VM via command line (from Dom0) --------------------------------------------------------------------------------- @@ -81,3 +80,31 @@ Disposable VMs and Local Forensics ---------------------------------- At this time, DispVMs should not be relied upon to circumvent local forensics, as they do not run entirely in RAM. For details, see [this thread](https://groups.google.com/d/topic/qubes-devel/QwL5PjqPs-4/discussion). + +Adding arbitrary programs to Disposable VM Application Menu +----------------------------------------------------------- + +For added convenience, arbitrary programs can be added to the Application Menu of the Disposable VM. In order to do that `arbitrary.desktop` file has to be created in `/usr/share/applications` that file will point to the desired program. Use following template when creating a .desktop file: + +`[Desktop Entry]`
+`Version=1.0`
+`Type=Application`
+`Exec=sh -c 'echo arbitrary | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'`
+`Icon=dispvm-red`
+`Terminal=false`
+`Name=DispVM: Arbitrary Name`
+`GenericName=DispVM: Arbitrary Generic Name`
+`StartupNotify=false`
+`Categories=Network;X-Qubes-VM;`
+ +Next, the /etc/xdg/menus/applications-merged/qubes-dispvm.menu file has to be modified so that it points to our newly-created .desktop file. + +Add `arbitrary.desktop` line to the `` block. The modified file should look like this: + +``
+`qubes-dispvm-firefox.desktop`
+`qubes-dispvm-xterm.desktop`
+`arbitrary.desktop`
+``
+ +After saving the changes our program should appear under the Disposable VM Applications menu. From abcf0fcccd7d7294157aec12f2e0c49c581cc44a Mon Sep 17 00:00:00 2001 From: Yethal Date: Sun, 12 Mar 2017 13:18:02 +0100 Subject: [PATCH 4/7] Update dispvm.md --- common-tasks/dispvm.md | 28 ---------------------------- 1 file changed, 28 deletions(-) diff --git a/common-tasks/dispvm.md b/common-tasks/dispvm.md index 3914eba3..2c7f9051 100644 --- a/common-tasks/dispvm.md +++ b/common-tasks/dispvm.md @@ -80,31 +80,3 @@ Disposable VMs and Local Forensics ---------------------------------- At this time, DispVMs should not be relied upon to circumvent local forensics, as they do not run entirely in RAM. For details, see [this thread](https://groups.google.com/d/topic/qubes-devel/QwL5PjqPs-4/discussion). - -Adding arbitrary programs to Disposable VM Application Menu ------------------------------------------------------------ - -For added convenience, arbitrary programs can be added to the Application Menu of the Disposable VM. In order to do that `arbitrary.desktop` file has to be created in `/usr/share/applications` that file will point to the desired program. Use following template when creating a .desktop file: - -`[Desktop Entry]`
-`Version=1.0`
-`Type=Application`
-`Exec=sh -c 'echo arbitrary | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red'`
-`Icon=dispvm-red`
-`Terminal=false`
-`Name=DispVM: Arbitrary Name`
-`GenericName=DispVM: Arbitrary Generic Name`
-`StartupNotify=false`
-`Categories=Network;X-Qubes-VM;`
- -Next, the /etc/xdg/menus/applications-merged/qubes-dispvm.menu file has to be modified so that it points to our newly-created .desktop file. - -Add `arbitrary.desktop` line to the `` block. The modified file should look like this: - -``
-`qubes-dispvm-firefox.desktop`
-`qubes-dispvm-xterm.desktop`
-`arbitrary.desktop`
-``
- -After saving the changes our program should appear under the Disposable VM Applications menu. From 29b335d205a9d35cd59897d4e3c78223b2875a83 Mon Sep 17 00:00:00 2001 From: Yethal Date: Sun, 12 Mar 2017 13:23:09 +0100 Subject: [PATCH 5/7] Fixed typo, added a line break --- common-tasks/dispvm.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/common-tasks/dispvm.md b/common-tasks/dispvm.md index 2c7f9051..1f5af78c 100644 --- a/common-tasks/dispvm.md +++ b/common-tasks/dispvm.md @@ -45,7 +45,8 @@ Use the `qvm-open-in-dvm` command line (from your AppVM), e.g.: [user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf ~~~ -The qvm-open-in-dvm will not exit until you close the application in the Disposable V +The qvm-open-in-dvm will not exit until you close the application in the Disposable VM. + Starting an arbitrary application in a disposable VM via command line (from Dom0) --------------------------------------------------------------------------------- From 71dac87a229ff4e8dbf712d72fef0041d823042b Mon Sep 17 00:00:00 2001 From: Yethal Date: Tue, 14 Mar 2017 02:32:10 +0100 Subject: [PATCH 6/7] Added a warning to USB mouse section --- common-tasks/usb.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/common-tasks/usb.md b/common-tasks/usb.md index ce83222f..5a6fd99a 100644 --- a/common-tasks/usb.md +++ b/common-tasks/usb.md @@ -158,8 +158,18 @@ How to use a USB mouse ---------------------- In order to use a USB mouse, you must first attach it to a USB qube, then -give that qube permission to pass mouse input to dom0. -Edit the `qubes.InputMouse` policy file in dom0, which is located here: +give that qube permission to pass mouse input to dom0. Note that allowing +mouse access from a USB qube gives it great power. In short: + + * It will be able to change any global and per-domain setting available within GUI + * It will be able to attach untrusted devices to domains that should not + have device access + * It will be able to enable networking in network-disconnected domains + * It will be able to initiate file transfer between domains. + (For more details, see [here][input-proxy].) + +If you are sure you wish to proceed, then you must edit the +`qubes.InputMouse` policy file in dom0, which is located here: /etc/qubes-rpc/policy/qubes.InputMouse From 54938518f12ed9701b69631d135d6b85722e421a Mon Sep 17 00:00:00 2001 From: Andrew David Wong Date: Thu, 16 Mar 2017 20:00:31 -0700 Subject: [PATCH 7/7] Adapt security warning from qubes-app-linux-input-proxy https://github.com/QubesOS/qubes-doc/pull/310 --- common-tasks/usb.md | 55 ++++++++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 25 deletions(-) diff --git a/common-tasks/usb.md b/common-tasks/usb.md index 5a6fd99a..33f5ae5d 100644 --- a/common-tasks/usb.md +++ b/common-tasks/usb.md @@ -128,21 +128,34 @@ directly to dom0. 7. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. 8. Reboot. + +Security Warning about USB Input Devices +---------------------------------------- + +**Important security warning. Please read this section carefully!** + +If you connect USB input devices (keyboard and mouse) to a VM, that VM will effectively have control over your system. +Because of this, the benefits of using a USB qube are much smaller than using a fully untrusted USB qube. +In addition to having control over your system, such VM can also sniff all the input your enter there (for example, passwords in the case of a USB keyboard). + +There is no simple way to protect against sniffing, but you can make it harder to exploit control over input devices. + +If you have only a USB mouse connected to a USB qube, but the keyboard is connected directly to dom0 (using a PS/2 connector, for example), you simply need to lock the screen when you are away from your computer. +You must do this every time you leave your computer unattended, even if there no risk of anyone else having direct physical access to your computer. +This is because you are guarding the system not only against anyone with local access, but also against possible actions from a potentially compromised USB qube. + +If your keyboard is also connected to a USB qube, things are much harder. +Locking the screen (with a traditional password) does not solve the problem, because the USB qube can simply sniff this password and later easily unlock the screen. +One possibility is to set up the screen locker to require an additional step to unlock (i.e., two-factor authentication). +One way to achieve this is to use a [YubiKey], or some other hardware token, or even to manually enter a one-time password. + How to use a USB keyboard ------------------------- -In order to use a USB keyboard, you must first attach it to a USB qube, then -give that qube permission to pass keyboard input to dom0. Note that allowing -keyboard access from a USB qube gives it great power. In short: +**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding. - * It will see whatever you type on that keyboard (including passwords). - * It will be able to inject keystrokes, which basically means that it will be - able to enter any command. For example, if some malware catches your - screenlocker password, it will be able to unlock the screen when you are not - present. (For more details, see [here][input-proxy].) - -If you are sure you wish to proceed, then you must edit the -`qubes.InputKeyboard` policy file in dom0, which is located here: +In order to use a USB keyboard, you must first attach it to a USB qube, then give that qube permission to pass keyboard input to dom0. +Edit the `qubes.InputKeyboard` policy file in dom0, which is located here: /etc/qubes-rpc/policy/qubes.InputKeyboard @@ -157,19 +170,10 @@ You can now use your USB keyboard. How to use a USB mouse ---------------------- -In order to use a USB mouse, you must first attach it to a USB qube, then -give that qube permission to pass mouse input to dom0. Note that allowing -mouse access from a USB qube gives it great power. In short: +**Caution:** Please carefully read the [Security Warning about USB Input Devices] before proceeding. - * It will be able to change any global and per-domain setting available within GUI - * It will be able to attach untrusted devices to domains that should not - have device access - * It will be able to enable networking in network-disconnected domains - * It will be able to initiate file transfer between domains. - (For more details, see [here][input-proxy].) - -If you are sure you wish to proceed, then you must edit the -`qubes.InputMouse` policy file in dom0, which is located here: +In order to use a USB mouse, you must first attach it to a USB qube, then give that qube permission to pass mouse input to dom0. +Edit the `qubes.InputMouse` policy file in dom0, which is located here: /etc/qubes-rpc/policy/qubes.InputMouse @@ -362,7 +366,8 @@ This feature is not yet available in Qubes Manager however, if you would like to [AEM]: /doc/anti-evil-maid/ [1618]: https://github.com/QubesOS/qubes-issues/issues/1618 [create a USB qube]: #creating-and-using-a-usb-qube -[input-proxy]: https://github.com/qubesos/qubes-app-linux-input-proxy [usb-challenges]: http://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html -[project-page]: https://www.qubes-os.org/gsoc/ +[project-page]: /gsoc/ [gsoc-page]: https://summerofcode.withgoogle.com/organizations/6239659689508864/ +[YubiKey]: /doc/YubiKey/ +[Security Warning about USB Input Devices]: #security-warning-about-usb-input-devices