mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-02 14:56:13 -04:00
Merge branch 'master' into spelling-grammar-fixes
Resolved conflicts in: basics_user/doc-guidelines.md basics_user/reporting-bugs.md common-tasks/backup-restore.md common-tasks/software-update-dom0.md common-tasks/software-update-vm.md common-tasks/usb.md configuration/disk-trim.md configuration/external-audio.md configuration/network-printer.md configuration/resize-disk-image.md configuration/resize-root-disk-image.md customization/fedora-minimal-template-customization.md managing-os/hvm.md managing-os/templates/archlinux.md privacy/whonix-install.md security/yubi-key.md troubleshooting/install-nvidia-driver.md troubleshooting/macbook-troubleshooting.md
This commit is contained in:
commit
919f2ed17e
123 changed files with 2914 additions and 1254 deletions
|
@ -8,31 +8,82 @@ redirect_from:
|
|||
- /wiki/DiskTRIM/
|
||||
---
|
||||
|
||||
VMs have already TRIM enabled by default, but dom0 doesn't. There are some security implications (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but IMO not very serious.
|
||||
Disk Trim
|
||||
----------
|
||||
|
||||
To enable TRIM in dom0 you need to:
|
||||
Disk trimming is the procedure by which the operating system informs the underlying storage device of which storage blocks are no longer in use.
|
||||
It does this by issuing an `ATA_TRIM` command for the block. This is also known as a `discard`.
|
||||
In this way, the storage device can perform garbage collection of the unused blocks and internally prepare them for reuse. SSDs in general benefit from this, while HDDs do not.
|
||||
|
||||
1. Get your LUKS device UUID:
|
||||
In a Linux system running on bare metal, this is relatively straight-forward.
|
||||
When instructed by the operating system, discards are issued by the file-system driver directly to the storage driver and then to the SSD.
|
||||
|
||||
In Qubes, this gets more complex due to virtualization, LUKS, and LVM (and thin pools on R4.0 and up).
|
||||
If you run `fstrim --all` inside a TemplateVM, in a worst case the `discard` can follow a path like:
|
||||
|
||||
OS -> File-system Driver -> Virtual Storage Driver -> Backend Storage Driver -> LVM Storage Driver -> LUKS Driver -> Physical Storage Driver -> Physical Storage Device
|
||||
|
||||
If discards are not supported at any one of those layers, it will not make it to the underlying physical device.
|
||||
|
||||
There are some security implications to permitting TRIM (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but in most cases not exploitable.
|
||||
|
||||
|
||||
Configuration
|
||||
----------
|
||||
|
||||
In all versions of Qubes, you may want to set up a periodic job in `dom0` to trim the disk.
|
||||
|
||||
This can be done from a terminal as root, by creating a `trim` file in `/etc/cron.daily` (or `/etc/cron.weekly`).
|
||||
Add the following contents:
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
/sbin/fstrim --all
|
||||
```
|
||||
|
||||
And mark it as executable with `chmod 755 /etc/cron.daily/trim`.
|
||||
|
||||
**Note** Although discards can be issued on every delete inside `dom0` by adding the `discard` mount option to `/etc/fstab`, this option can hurt performance so the above procedure is recommended instead.
|
||||
However, inside App and Template qubes, the `discard` mount option is on by default to notify the LVM thin pool driver (R4.0) or sparse file driver (R3.2) that the space is no longer needed and can be zeroed and re-used.
|
||||
|
||||
If you are using Qubes with LVM, you may also want to set `issue_discards = 1` in `/etc/lvm/lvm.conf`.
|
||||
Setting this option will permit LVM to issue discards to the SSD when logical volumes are shrunk or deleted.
|
||||
In R4.x, LVM Logical volumes are frequently deleted (every time a disposable VM is shut down, for example) so setting `issue_discards = 1` is recommended if using an SSD.
|
||||
However, this is relatively rare in R3.x.
|
||||
|
||||
|
||||
LUKS
|
||||
----------
|
||||
|
||||
If you have enabled LUKS in dom0, discards will not get passed down to the storage device.
|
||||
|
||||
To enable TRIM support in dom0 with LUKS you need to:
|
||||
|
||||
1. Get your LUKS device UUID:
|
||||
|
||||
~~~
|
||||
ls /dev/mapper/luks-*
|
||||
~~~
|
||||
|
||||
2. Add entry to `/etc/crypttab` (replace luks-\<UUID\> with the device name and the \<UUID\> with UUID alone):
|
||||
2. Add entry to `/etc/crypttab` (replace luks-\<UUID\> with the device name and the \<UUID\> with UUID alone):
|
||||
|
||||
~~~
|
||||
luks-<UUID> UUID=<UUID> none allow-discards
|
||||
luks-<UUID> UUID=<UUID> none discard
|
||||
~~~
|
||||
|
||||
3. Add `rd.luks.allow-discards=1` to kernel cmdline (`/etc/default/grub`, GRUB\_CMDLINE\_LINUX line)
|
||||
4. Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
|
||||
5. Rebuild initrd **in hostonly mode**:
|
||||
3. Add `rd.luks.options=discard` to kernel cmdline (follow either GRUB2 or EFI, not both):
|
||||
* GRUB2: `/etc/default/grub`, `GRUB_CMDLINE_LINUX` line and
|
||||
Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
|
||||
* EFI: `/boot/efi/EFI/qubes/xen.cfg`, `kernel=` line(s)
|
||||
|
||||
4. Rebuild initrd **in hostonly mode**:
|
||||
|
||||
~~~
|
||||
dracut -H -f
|
||||
~~~
|
||||
|
||||
6. Add "discard" option to `/etc/fstab` for root device
|
||||
7. Reboot the system, verify that allow-discards is really enabled (`dmsetup table`)
|
||||
5. Reboot the system.
|
||||
|
||||
6. To verify if discards are enabled you may use `dmsetup table` (confirm the line for your device mentions "discards") or just run `fstrim -av` (you should see a `/` followed by the number of bytes trimmed).
|
||||
|
||||
|
||||
There is a [bug affecting allow-discards option](https://bugzilla.redhat.com/show_bug.cgi?id=890533), once it will be fixed, first two steps will be no longer needed.
|
||||
|
|
|
@ -14,19 +14,24 @@ Using External Audio Devices
|
|||
Why you want to use external audio devices
|
||||
------------------------------------------
|
||||
|
||||
Qubes audio virtualization protocol does not implement latency reporting for security reasons, keeping the protocol as simple as possible. Also, in a compromise between low latency and low CPU usage, latency may be around 200 ms. So applications demanding higher audio quality (even Skype) need a better environment. But Qubes flexibility fully allows that using external audio devices. These are mostly USB audio cards, but firewire devices also might be used.
|
||||
Qubes audio virtualization protocol does not implement latency reporting for security reasons, keeping the protocol as simple as possible.
|
||||
Also, in a compromise between low latency and low CPU usage, latency may be around 200 ms.
|
||||
So applications demanding higher audio quality (even Skype) need a better environment.
|
||||
But Qubes flexibility fully allows that using external audio devices.
|
||||
These are mostly USB audio cards, but firewire devices also might be used.
|
||||
|
||||
Implementing external audio devices
|
||||
-----------------------------------
|
||||
|
||||
First you need to identify an user VM dedicated to audio and [assign a device](/doc/AssigningDevices) to it. In the most common case the assigned device is the USB controller to which your USB audio card will be connected.
|
||||
First you need to identify an user VM dedicated to audio and [assign a device](/doc/AssigningDevices) to it.
|
||||
In the most common case the assigned device is the USB controller to which your USB audio card will be connected.
|
||||
|
||||
### Fedora VMs
|
||||
|
||||
In a terminal of the template from which you user VM depends, install pavucontrol with:
|
||||
|
||||
~~~
|
||||
sudo yum install pavucontrol
|
||||
sudo dnf install pavucontrol
|
||||
~~~
|
||||
|
||||
Close the template and start or restart your user VM, insert your external audio device, open a terminal and prepare pulseaudio to use it with:
|
||||
|
@ -38,9 +43,10 @@ pactl load-module module-udev-detect
|
|||
|
||||
Start the audio application that is going to use the external audio device.
|
||||
|
||||
Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select your external audio card in pavucontrol. You need to do that only the first time you use a new external audio device, then pulse audio will remember your selection.
|
||||
Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select your external audio card in pavucontrol.
|
||||
You need to do that only the first time you use a new external audio device, then pulse audio will remember your selection.
|
||||
|
||||
If you detach your external audio device, then want to insert it again, or change it with another one, you need to repeat the previous commands in terminal, adding another line at the beginning:
|
||||
If you detach your external audio device, then want to insert it again (or want to change it with another one), you need to repeat the previous commands in terminal adding another line at the beginning:
|
||||
|
||||
~~~
|
||||
pactl unload-module module-udev-detect
|
||||
|
|
|
@ -16,7 +16,7 @@ Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its s
|
|||
Installation
|
||||
------------
|
||||
|
||||
`yum install fetchmail`
|
||||
`dnf install fetchmail`
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
|
|
@ -14,27 +14,42 @@ Configuring a network printer for Qubes AppVMs
|
|||
Where to configure printers and install drivers?
|
||||
------------------------------------------------
|
||||
|
||||
One would normally want to configure a printer in a template VM, rather than in particular AppVMs. This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown. When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
|
||||
One would normally want to configure a printer in a template VM, rather than in particular AppVMs.
|
||||
This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown.
|
||||
When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
|
||||
|
||||
Alternatively one can add a printer in a standalone VM, but this would limit the printer usage to this particular VM.
|
||||
|
||||
Security considerations for network printers and drivers
|
||||
--------------------------------------------------------
|
||||
|
||||
Some printers require 3rd party drivers, typically downloadable from the vendor's website. Such drivers are typically distributed in a form of ready to install RPM packages. However, they are often unsigned, and additionally the downloads are available via HTTP connections only. As a result, installation of such 3rd party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template. (Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
|
||||
Some printers require third-party drivers, typically downloadable from the vendor's website.
|
||||
Such drivers are typically distributed in a form of ready to install RPM packages.
|
||||
However, they are often unsigned, and additionally the downloads are available via HTTP connections only.
|
||||
As a result, installation of such third-party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template.
|
||||
(Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
|
||||
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the 3rd party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there. This would allow to print documents from more trusted AppVMs (based on a trusted default template, that is not poisoned by 3rd party printer drivers).
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the third-party, unverified drivers there.
|
||||
Such template might then be made a DVM template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there.
|
||||
This would allow to print documents from more trusted AppVMs (based on a trusted default template that is not poisoned by third-party printer drivers).
|
||||
|
||||
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
|
||||
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols.
|
||||
This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed.
|
||||
This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
|
||||
|
||||
Additionally, the printer drivers as well as CUPS application itself, might be buggy and might get exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM). Consider not using printing from your more trusted AppVMs for this reason.
|
||||
Additionally, the printer drivers as well as CUPS application itself, might be buggy and might get exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM).
|
||||
Consider not using printing from your more trusted AppVMs for this reason.
|
||||
|
||||
Steps to configure a network printer in a template VM
|
||||
----------------------------------------------------------
|
||||
|
||||
1. Start the "Printer Settings" App in a template VM (either via Qubes "Start Menu", or by launching the `system-config-printer` in the template).
|
||||
2. Add/Configure the printer in the same way as one would do on any normal Linux. Be sure to allow network access from the template VM to your printer, as normally the template VM is not allowed any network access, except to the Qubes proxy for software installation. One can use Qubes Manager to modify firewall rules for particular VMs.
|
||||
2. Add/Configure the printer in the same way as one would do on any normal Linux.
|
||||
You may need to allow network access from the template VM to your printer to complete configuration, as normally the template VM is not allowed any network access except to the Qubes proxy for software installation.
|
||||
One can use Qubes Manager to modify firewall rules for particular VMs.
|
||||
3. Optional: Test the printer by printing a test page. If it works, shut down the template VM.
|
||||
4. Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works. If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager. Also, make sure that the AppVM gets restarted after the template was shutdown.
|
||||
4. Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works.
|
||||
If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager.
|
||||
Also, make sure that the AppVM gets restarted after the template was shutdown.
|
||||
5. Alternatively if you do not want to modify the firewall rules of the template VM (that have security scope) you can simply shut down the template VM without trying to print the test page (which will not work), start or restart an AppVM based on the template and test printing there.
|
||||
|
||||
|
|
|
@ -16,11 +16,11 @@ Postfix is full featured MTA (Message Transfer Agent). Here we will configure it
|
|||
Installation
|
||||
------------
|
||||
|
||||
`yum install postfix procmail make cyrus-sasl cyrus-sasl-plain`
|
||||
`dnf install postfix procmail make cyrus-sasl cyrus-sasl-plain`
|
||||
|
||||
Cyrus-sasl is installed to authenticate to remote servers. Procmail is not strictly necessary, but is useful to sort your incoming mail, for example to put each mailing list in its own directory. Make is also not necessary, but is used to keep Postfix lookup tables.
|
||||
|
||||
You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `yum remove ssmtp` or something
|
||||
You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `dnf remove ssmtp` or something
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Resize Disk Image
|
||||
title: Resize Private Disk Image
|
||||
permalink: /doc/resize-disk-image/
|
||||
redirect_from:
|
||||
- /en/doc/resize-disk-image/
|
||||
|
@ -8,40 +8,65 @@ redirect_from:
|
|||
- /wiki/ResizeDiskImage/
|
||||
---
|
||||
|
||||
Resize Disk Image
|
||||
Resize Private Disk Image
|
||||
-----------------
|
||||
|
||||
There are several disk images which can be easily extended. But pay attention to the overall consumed space of your sparse disk images.
|
||||
There are several disk images which can be easily extended, but pay attention to the overall consumed space of your sparse disk images.
|
||||
See also additional information and caveats about [resizing the root disk image](/doc/resize-root-disk-image/).
|
||||
|
||||
### Private disk image
|
||||
|
||||
1048576 MB is the maximum size which can be assigned to a private storage through qubes-manager.
|
||||
### Private disk image (R4.0)
|
||||
|
||||
To grow the private disk image of a AppVM beyond this limit [qubes-grow-private](/doc/dom0-tools/qvm-grow-private/) can be used:
|
||||
1048576 MiB is the maximum size which can be assigned to private storage through Qube Manager.
|
||||
|
||||
To grow the private disk image of an AppVM beyond this limit, `qvm-volume` can be used:
|
||||
|
||||
~~~
|
||||
qvm-volume extend <vm_name>:private <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Private disk image (R3.2)
|
||||
|
||||
1048576 MB is the maximum size which can be assigned to private storage through Qubes Manager.
|
||||
|
||||
To grow the private disk image of an AppVM beyond this limit, [qvm-grow-private](/doc/dom0-tools/qvm-grow-private/) can be used:
|
||||
|
||||
~~~
|
||||
qvm-grow-private <vm-name> <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Shrinking private disk image (Linux VM)
|
||||
### Shrinking private disk image (Linux VM, R4.0)
|
||||
|
||||
**This operation is dangerous and this is why it isn't available in standard Qubes tools. If you have enough disk space, it is safer to create new VM with smaller disk and move the data.**
|
||||
1. Create a new qube with smaller disk using Qube Manager or `qvm-create`
|
||||
2. Move data to the new qube using `qvm-copy` or OS utilities
|
||||
3. Delete old qube using Qube Manager or `qvm-remove`
|
||||
|
||||
### Shrinking private disk image (Linux VM, R3.2)
|
||||
|
||||
**This operation is dangerous and this is why it isn't available in standard Qubes tools.
|
||||
If you have enough disk space, it is safer to create a new VM with a smaller disk and move the data.**
|
||||
|
||||
The basic idea is to:
|
||||
|
||||
1. Shrink filesystem on the private disk image.
|
||||
2. Then shrink the image.
|
||||
|
||||
Ext4 does not support online shrinking, so can't be done as convenient as image grown. Note that we don't want to touch the VM filesystem directly in dom0 for security reasons. First you need to start VM without `/rw` mounted. One of the possibilities is to interrupt its normal startup by adding `rd.break` kernel option:
|
||||
Ext4 does not support online shrinking, so it can't be done as conveniently as growing the image.
|
||||
Note that we don't want to touch the VM filesystem directly in dom0 for security reasons.
|
||||
First you need to start VM without `/rw` mounted.
|
||||
One possibility is to interrupt its normal startup by adding the `rd.break` kernel option:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s <vm-name> kernelopts rd.break
|
||||
qvm-start --no-guid <vm-name>
|
||||
~~~
|
||||
|
||||
And wait for qrexec connect timeout (or simply press Ctrl-C). Then you can connect to VM console and shrink the filesystem:
|
||||
And wait for qrexec connect timeout (or simply press Ctrl-C).
|
||||
Then you can connect to VM console and shrink the filesystem:
|
||||
|
||||
~~~
|
||||
sudo xl console <vm-name>
|
||||
|
@ -63,7 +88,9 @@ Now you can resize the image:
|
|||
truncate -s <new-desired-size> /var/lib/qubes/appvms/<vm-name>/private.img
|
||||
~~~
|
||||
|
||||
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call. Otherwise you will lose your data!** Then reset kernel options back to default:
|
||||
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call.
|
||||
Otherwise you will lose your data!**
|
||||
Then reset kernel options back to default:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s <vm-name> kernelopts default
|
||||
|
@ -71,38 +98,18 @@ qvm-prefs -s <vm-name> kernelopts default
|
|||
|
||||
Done.
|
||||
|
||||
### Template disk image
|
||||
>In order to avoid error, you might want to first reduce the filesystem to a smaller size than desired (say 3G), then truncate the image to the target size (for example 4G), and lastly grow the filesystem to the target size.
|
||||
>In order to do this, after the `truncate` step, start the vm again in maintenance mode and use the following command to extend the filesystem to the correct size : `resize2fs /dev/xvdb`.
|
||||
>
|
||||
>With no argument, resize2fs grows the filesystem to match the underlying block device (the .img file you just shrunk).
|
||||
|
||||
If you want install a lot of software in your TemplateVM, you may need to increase the amount of disk space your TemplateVM can use. See also additional information and caveats about [resizing the root disk image].
|
||||
|
||||
1. Make sure that all the VMs based on this template are shut down (including netvms etc).
|
||||
2. Sanity check: verify that none of the loop devices are pointing at this template root.img. Run this in dom0: `sudo losetup -a`
|
||||
3. Resize root.img file. Run this in dom0: `truncate -s <desired size> <path to root.img>` (the root.img path can be obtained from qvm-prefs).
|
||||
4. If any netvm/proxyvm used by this template is based on it, set template netvm to none.
|
||||
5. Start the template.
|
||||
6. Execute `sudo resize2fs /dev/mapper/dmroot` in the template.
|
||||
7. Verify available space in the template using `df -h`
|
||||
8. Shutdown the template.
|
||||
9. Restore original netvm setting (if changed), check firewall settings (setting netvm to none causes firewall reset to "block all")
|
||||
OS Specific Follow-up Instructions
|
||||
-----------------
|
||||
|
||||
### HVM disk image
|
||||
|
||||
In this example we will grow the disk image of an HVM to 30GB.
|
||||
|
||||
First, stop/shutdown the HVM.
|
||||
|
||||
Then, from a Dom0 terminal (in KDE: System Tools -\> Terminal Emulator) do the following:
|
||||
|
||||
~~~
|
||||
cd /var/lib/qubes/appvms/<yourHVM>/
|
||||
ls -lh root.img (<--verify current size of disk image)
|
||||
truncate -s 30GB root.img
|
||||
ls -lh root.img (<--verify new size of disk image)
|
||||
~~~
|
||||
|
||||
The partition table and file-system must be adjusted after this change.
|
||||
Use tools appropriate to the OS in your HVM. Brief instructions for Windows 7,
|
||||
FreeBSD, and Linux are provided below.
|
||||
After resizing volumes, the partition table and file-system may need to be adjusted.
|
||||
Use tools appropriate to the OS in your qube.
|
||||
Brief instructions for Windows 7, FreeBSD, and Linux are provided below.
|
||||
|
||||
#### Windows 7
|
||||
|
||||
|
@ -124,8 +131,6 @@ zpool online -e poolname ada0
|
|||
|
||||
#### Linux
|
||||
|
||||
Qubes will automatically grow the filesystem for you on AppVMs but not HVMs.
|
||||
You will see that there is unallocated free space at the end of your primary disk.
|
||||
You can use standard linux tools like fdisk and mkfs to make this space available.
|
||||
|
||||
|
||||
[resizing the root disk image]: https://www.qubes-os.org/doc/resize-root-disk-image/
|
||||
|
|
|
@ -11,11 +11,53 @@ redirect_from:
|
|||
Resize Root Disk Image
|
||||
----------------------
|
||||
|
||||
The safest way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM. Doing this means it will have its own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*. To do this run `qvm-create --standalone` from `dom0` Konsole.
|
||||
See additional information and caveats about [resizing private disk images](/doc/resize-disk-image/), paying particular attention to "OS Specific Follow-up Instructions" at the end.
|
||||
|
||||
### Resize a StandaloneVM Root Image
|
||||
### Template disk image
|
||||
|
||||
In `dom0` Konsole run the following command (replace the size and path):
|
||||
If you want install a lot of software in your TemplateVM, you may need to increase the amount of disk space your TemplateVM can use.
|
||||
*Make sure changes in the TemplateVM between reboots don't exceed 10G.*
|
||||
|
||||
1. Make sure that all the VMs based on this template are shut down (including netvms etc).
|
||||
2. Resize root image using Qubes version specific procedure below.
|
||||
3. If any netvm/proxyvm used by this template is based on it, set template's netvm to none.
|
||||
4. Start the template.
|
||||
5. Resize the filesystem using OS appropriate tools (Qubes will handle this automatically with Linux templates).
|
||||
6. Verify available space in the template using `df -h` or OS specific tools.
|
||||
7. Shutdown the template.
|
||||
8. Restore original netvm setting (if changed), check firewall settings (setting netvm to none causes the firewall to reset to "block all")
|
||||
|
||||
### Root disk image (R4.0)
|
||||
|
||||
1048576 MiB is the maximum size which can be assigned to root storage through Qube Manager.
|
||||
|
||||
To grow the root disk image of an AppVM beyond this limit, `qvm-volume` can be used:
|
||||
|
||||
~~~
|
||||
qvm-volume extend <vm_name>:root <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Root disk image (R3.2)
|
||||
|
||||
1048576 MB is the maximum size which can be assigned to root storage through Qubes Manager.
|
||||
|
||||
To grow the root disk image of an AppVM beyond this limit, `qvm-grow-root` can be used:
|
||||
|
||||
~~~
|
||||
qvm-grow-root <vm-name> <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Resize a StandaloneVM Root Image (R3.2)
|
||||
|
||||
Another way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM.
|
||||
Doing this means it will have it's own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*.
|
||||
To do this run `qvm-create --standalone` from `dom0` console.
|
||||
|
||||
In `dom0` console run the following command (replace the size and path):
|
||||
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/appvms/standalonevm/root.img
|
||||
|
@ -27,28 +69,4 @@ Then start Terminal for this StandaloneVM and run:
|
|||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
Shutdown the StandaloneVM and you will have extended the size of its `root.img`
|
||||
|
||||
|
||||
### Resize a TemplateVM Root Image
|
||||
|
||||
Shut down the TemplateVM, as well as all VMs based on that template (since they
|
||||
share `root.img`).
|
||||
In `dom0` Konsole run the following command (replace the size and path):
|
||||
*Make sure changes in the TemplateVM between reboots didn't exceed 10G.*
|
||||
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img
|
||||
~~~
|
||||
|
||||
Then start only the TemplateVM and run the following. Note that if you are
|
||||
resizing the TemplateVM used by, e.g., your NetVM, you may need to disable
|
||||
networking so when the TemplateVM is started, it does not autostart other VMs
|
||||
based on the same `root.img`. Otherwise you will get an error message `Nothing
|
||||
to do!`.
|
||||
|
||||
~~~
|
||||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
Shutdown the TemplateVM and you will have extended the size of its `root.img`.
|
||||
Shutdown the StandaloneVM and you will have extended the size of its `root.img`.
|
||||
|
|
|
@ -16,12 +16,16 @@ Rxvt
|
|||
Installation
|
||||
------------
|
||||
|
||||
`yum install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension. Let me also recommend excellent Terminus font: `yum install terminus-fonts`.
|
||||
`dnf install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension.
|
||||
Let me also recommend excellent Terminus font: `dnf install terminus-fonts`.
|
||||
|
||||
Xresources
|
||||
----------
|
||||
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below. `!`-lines are comments and may be left out. `#`-lines are directives to CPP (C preprocessor) and are necessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below.
|
||||
`!`-lines are comments and may be left out.
|
||||
`#`-lines are directives to CPP (C preprocessor) and are necessary.
|
||||
This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
|
||||
~~~
|
||||
! CGA colour palette
|
||||
|
@ -132,7 +136,8 @@ URxvt.insecure: False
|
|||
!URxvt.termName: rxvt-256color
|
||||
~~~
|
||||
|
||||
Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
|
||||
Then create script to automatically merge those to xrdb.
|
||||
File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
|
||||
|
||||
~~~
|
||||
#!/bin/sh
|
||||
|
@ -143,4 +148,5 @@ Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xi
|
|||
Shortcuts
|
||||
---------
|
||||
|
||||
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*. Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.
|
||||
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*.
|
||||
Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.
|
||||
|
|
|
@ -39,7 +39,7 @@ Known Issues
|
|||
dom0.) Do not attempt to detach these disks. (They will automatically be
|
||||
detached when you shut down the AppVM.) [[2]]
|
||||
|
||||
[Qubes Backup]: https://www.qubes-os.org/doc/BackupRestore/
|
||||
[TemplateVM]: https://www.qubes-os.org/doc/Templates/
|
||||
[Qubes Backup]: /doc/BackupRestore/
|
||||
[TemplateVM]: /doc/Templates/
|
||||
[1]: https://groups.google.com/d/topic/qubes-users/EITd1kBHD30/discussion
|
||||
[2]: https://groups.google.com/d/topic/qubes-users/nDrOM7dzLNE/discussion
|
||||
|
|
|
@ -20,8 +20,8 @@ Please refer to your guest OS and VPN service documentation when considering the
|
|||
|
||||
The simplest case is to set up a VPN connection using the NetworkManager service inside your NetVM. Because the NetworkManager service is already started, you are ready to set up your VPN connection. However this has some disadvantages:
|
||||
|
||||
- You have to place (and probably save) your VPN credentials inside the NetVM, which is directly connected to the outside world
|
||||
- All your AppVMs which are connected to the NetVM will be connected to the VPN (by default)
|
||||
- You have to place (and probably save) your VPN credentials inside the NetVM, which is directly connected to the outside world
|
||||
- All your AppVMs which are connected to the NetVM will be connected to the VPN (by default)
|
||||
|
||||
### AppVM
|
||||
|
||||
|
@ -33,26 +33,26 @@ One of the best unique features of Qubes OS is its special type of VM called a P
|
|||
|
||||
Using a ProxyVM to set up a VPN client gives you the ability to:
|
||||
|
||||
- Separate your VPN credentials from your NetVM.
|
||||
- Separate your VPN credentials from your AppVM data.
|
||||
- Easily control which of your AppVMs are connected to your VPN by simply setting it as a NetVM of the desired AppVM.
|
||||
- Separate your VPN credentials from your NetVM.
|
||||
- Separate your VPN credentials from your AppVM data.
|
||||
- Easily control which of your AppVMs are connected to your VPN by simply setting it as a NetVM of the desired AppVM.
|
||||
|
||||
Set up a ProxyVM as a VPN gateway using NetworkManager
|
||||
------------------------------------------------------
|
||||
|
||||
1. Create a new VM, name it, click the ProxyVM radio button, and choose a color and template.
|
||||
1. Create a new VM, name it, click the ProxyVM radio button, and choose a color and template.
|
||||
|
||||

|
||||

|
||||
|
||||
2. Add the `network-manager` service to this new VM.
|
||||
2. Add the `network-manager` service to this new VM.
|
||||
|
||||

|
||||

|
||||
|
||||
3. Set up your VPN as described in the NetworkManager documentation linked above.
|
||||
3. Set up your VPN as described in the NetworkManager documentation linked above.
|
||||
|
||||
4. Configure your AppVMs to use the new VM as a NetVM.
|
||||
4. Configure your AppVMs to use the new VM as a NetVM.
|
||||
|
||||

|
||||

|
||||
|
||||
5. Optionally, you can install some [custom icons](https://github.com/Zrubi/qubes-artwork-proxy-vpn) for your VPN
|
||||
|
||||
|
@ -60,140 +60,206 @@ Set up a ProxyVM as a VPN gateway using NetworkManager
|
|||
Set up a ProxyVM as a VPN gateway using iptables and CLI scripts
|
||||
----------------------------------------------------------------
|
||||
|
||||
This method is more involved than the one above, but has anti-leak features that also make the connection _fail closed_ should it be interrupted. It has been tested with Fedora 23 and Debian 8 templates.
|
||||
This method is more involved than the one above, but has anti-leak features that also make the connection _fail closed_ should it be interrupted.
|
||||
It has been tested with Fedora 23 and Debian 8 templates.
|
||||
|
||||
1. Create a new VM, name it, click the ProxyVM radio button, and choose a color and template.
|
||||
|
||||

|
||||
|
||||
Note: Do not enable NetworkManager in the ProxyVM, as it can interfere with the scripts' DNS features. If you enabled NetworkManager or used other methods in a previous attempt, do not re-use the old ProxyVM... Create a new one according to this step.
|
||||
|
||||
If your choice of template VM doesn't already have the VPN client software, you'll need to install the software in the template before proceeding. Disable any auto-starting service that comes with the software package: for example `sudo systemctl disable openvpn.service`.
|
||||
|
||||
You may also wish to install `nano` or another simple text editor for entering the scripts below.
|
||||

|
||||
|
||||
2. Set up and test the VPN client.
|
||||
Note: Do not enable NetworkManager in the ProxyVM, as it can interfere with the scripts' DNS features.
|
||||
If you enabled NetworkManager or used other methods in a previous attempt, do not re-use the old ProxyVM...
|
||||
Create a new one according to this step.
|
||||
|
||||
Make sure the VPN VM and its template VM are not running.
|
||||
|
||||
Run a terminal (CLI) in the VPN VM -- this will start the VM. Then make a new 'vpn' folder with `sudo mkdir /rw/config/vpn` and copy your VPN config files here (the example config filename used here is `openvpn-client.ovpn`). Files accompanying the main config such as *.crt and *.pem should also go here, and should not be referenced in the main config by absolute paths such as '/etc/...'.
|
||||
If your choice of TemplateVM doesn't already have the VPN client software, you'll need to install the software in the template before proceeding.
|
||||
Disable any auto-starting service that comes with the software package.
|
||||
For example for OpenVPN.
|
||||
|
||||
Notes about VPN config options: The VPN scripts here are intended to work with commonly used `tun` interfaces, whereas `tap` mode is untested. Also, the config should route all traffic through your VPN's interface after a connection is created; For openvpn the directive for this is `redirect-gateway def1`. Lastly, the VPN client may not be able to prompt you for credentials when connecting to the server: Creating a file in the 'vpn' folder with your credentials and using a directive such as openvpn's `auth-user-pass <filename>` is recommended.
|
||||
|
||||
__Test your client configuration:__ Run the client from a CLI prompt in the 'vpn' folder, preferably as root. For example:
|
||||
```
|
||||
sudo openvpn --cd /rw/config/vpn --config openvpn-client.ovpn
|
||||
```
|
||||
|
||||
Watch for status messages that indicate whether the connection is successful and test from another VPN VM terminal window with `ping` and `traceroute`. DNS may be tested at this point by replacing addresses in `/etc/resolv.conf` with ones appropriate for your VPN (although this file will not be used when setup is complete). Diagnose any connection problems using resources such as client documentation and help from your VPN service provider.
|
||||
|
||||
Proceed to the next step when you're sure the basic VPN connection is working.
|
||||
sudo systemctl disable openvpn.service
|
||||
|
||||
3. Create the DNS-handling script.
|
||||
Use `sudo nano /rw/config/vpn/qubes-vpn-handler.sh` to edit and add:
|
||||
You may also wish to install `nano` or another simple text editor for entering the scripts below.
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
set -e
|
||||
export PATH="$PATH:/usr/sbin:/sbin"
|
||||
2. Set up and test the VPN client.
|
||||
Make sure the VPN VM and its TemplateVM is not running.
|
||||
Run a terminal (CLI) in the VPN VM -- this will start the VM.
|
||||
Then create a new `/rw/config/vpn` folder with.
|
||||
|
||||
case "$1" in
|
||||
sudo mkdir /rw/config/vpn
|
||||
|
||||
up)
|
||||
# To override DHCP DNS, assign DNS addresses to 'vpn_dns' env variable before calling this script;
|
||||
# Format is 'X.X.X.X Y.Y.Y.Y [...]'
|
||||
if [[ -z "$vpn_dns" ]] ; then
|
||||
# Parses DHCP foreign_option_* vars to automatically set DNS address translation:
|
||||
for optionname in ${!foreign_option_*} ; do
|
||||
option="${!optionname}"
|
||||
unset fops; fops=($option)
|
||||
if [ ${fops[1]} == "DNS" ] ; then vpn_dns="$vpn_dns ${fops[2]}" ; fi
|
||||
done
|
||||
fi
|
||||
Copy your VPN config files to `/rw/config/vpn`.
|
||||
Your VPN config file should be named `openvpn-client.ovpn`) so you can use the scripts below as is without modification.
|
||||
Otherwise you would have to replace the file name.
|
||||
`openvpn-client.ovpn` contents:
|
||||
|
||||
iptables -t nat -F PR-QBS
|
||||
if [[ -n "$vpn_dns" ]] ; then
|
||||
# Set DNS address translation in firewall:
|
||||
for addr in $vpn_dns; do
|
||||
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
|
||||
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr
|
||||
done
|
||||
su - -c 'notify-send "$(hostname): LINK IS UP." --icon=network-idle' user
|
||||
else
|
||||
su - -c 'notify-send "$(hostname): LINK UP, NO DNS!" --icon=dialog-error' user
|
||||
fi
|
||||
* Files accompanying the main config such as `*.crt` and `*.pem` should also go to `/rw/config/vpn` folder.
|
||||
* Files referenced in `openvpn-client.ovpn` should not use absolute paths such as `/etc/...`.
|
||||
|
||||
;;
|
||||
down)
|
||||
su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user
|
||||
;;
|
||||
esac
|
||||
~~~
|
||||
The VPN scripts here are intended to work with commonly used `tun` interfaces, whereas `tap` mode is untested.
|
||||
Also, the config should route all traffic through your VPN's interface after a connection is created; For OpenVPN the directive for this is `redirect-gateway def1`.
|
||||
|
||||
Now save the script and make it executable:
|
||||
`sudo chmod +x /rw/config/vpn/qubes-vpn-handler.sh`
|
||||
|
||||
4. Configure client to use the DNS handling script. Using openvpn as an example, edit the config with `sudo nano /rw/config/vpn/openvpn-client.ovpn` and add these lines:
|
||||
sudo nano /rw/config/vpn/openvpn-client.ovpn
|
||||
|
||||
~~~
|
||||
script-security 2
|
||||
up 'qubes-vpn-handler.sh up'
|
||||
down 'qubes-vpn-handler.sh down'
|
||||
~~~
|
||||
Make sure it already includes or add:
|
||||
|
||||
**Restart the client and test the connection again** ...this time from an AppVM!
|
||||
redirect-gateway def1
|
||||
|
||||
5. Set up iptables anti-leak rules.
|
||||
The VPN client may not be able to prompt you for credentials when connecting to the server.
|
||||
Create a file in the `/rw/config/vpn` folder with your credentials and using a directive.
|
||||
For example for OpenVPN, add:
|
||||
|
||||
Edit the firewall script with `sudo nano /rw/config/qubes-firewall-user-script` then clear out the existing lines and add:
|
||||
auth-user-pass pass.txt
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
# Block forwarding of connections through upstream network device
|
||||
# (in case the vpn tunnel breaks):
|
||||
iptables -I FORWARD -o eth0 -j DROP
|
||||
iptables -I FORWARD -i eth0 -j DROP
|
||||
|
||||
# Block all outgoing traffic
|
||||
iptables -P OUTPUT DROP
|
||||
iptables -F OUTPUT
|
||||
iptables -I OUTPUT -o lo -j ACCEPT
|
||||
Save file `/rw/config/vpn/openvpn-client.ovpn`.
|
||||
Make sure a `/rw/config/vpn/pass.txt` file actually exists.
|
||||
|
||||
# Add the `qvpn` group to system, if it doesn't already exist
|
||||
if ! grep -q "^qvpn:" /etc/group ; then
|
||||
sudo nano /rw/config/vpn/pass.txt
|
||||
|
||||
Add:
|
||||
|
||||
username
|
||||
password
|
||||
|
||||
Replace `username` and `password` with your actual username and password.
|
||||
|
||||
**Test your client configuration:**
|
||||
Run the client from a CLI prompt in the 'vpn' folder, preferably as root.
|
||||
For example:
|
||||
|
||||
sudo openvpn --cd /rw/config/vpn --config openvpn-client.ovpn
|
||||
|
||||
Watch for status messages that indicate whether the connection is successful and test from another VPN VM terminal window with `ping`.
|
||||
|
||||
ping 8.8.8.8
|
||||
|
||||
`ping` can be aborted by pressing the two keys `ctrl` + `c` at the same time.
|
||||
DNS may be tested at this point by replacing addresses in `/etc/resolv.conf` with ones appropriate for your VPN (although this file will not be used when setup is complete).
|
||||
Diagnose any connection problems using resources such as client documentation and help from your VPN service provider.
|
||||
Proceed to the next step when you're sure the basic VPN connection is working.
|
||||
|
||||
3. Create the DNS-handling script.
|
||||
|
||||
sudo nano /rw/config/vpn/qubes-vpn-handler.sh
|
||||
|
||||
Edit and add:
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
set -e
|
||||
export PATH="$PATH:/usr/sbin:/sbin"
|
||||
|
||||
case "$1" in
|
||||
|
||||
up)
|
||||
# To override DHCP DNS, assign DNS addresses to 'vpn_dns' env variable before calling this script;
|
||||
# Format is 'X.X.X.X Y.Y.Y.Y [...]'
|
||||
if [[ -z "$vpn_dns" ]] ; then
|
||||
# Parses DHCP foreign_option_* vars to automatically set DNS address translation:
|
||||
for optionname in ${!foreign_option_*} ; do
|
||||
option="${!optionname}"
|
||||
unset fops; fops=($option)
|
||||
if [ ${fops[1]} == "DNS" ] ; then vpn_dns="$vpn_dns ${fops[2]}" ; fi
|
||||
done
|
||||
fi
|
||||
|
||||
iptables -t nat -F PR-QBS
|
||||
if [[ -n "$vpn_dns" ]] ; then
|
||||
# Set DNS address translation in firewall:
|
||||
for addr in $vpn_dns; do
|
||||
iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $addr
|
||||
iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $addr
|
||||
done
|
||||
su - -c 'notify-send "$(hostname): LINK IS UP." --icon=network-idle' user
|
||||
else
|
||||
su - -c 'notify-send "$(hostname): LINK UP, NO DNS!" --icon=dialog-error' user
|
||||
fi
|
||||
|
||||
;;
|
||||
down)
|
||||
su - -c 'notify-send "$(hostname): LINK IS DOWN !" --icon=dialog-error' user
|
||||
;;
|
||||
esac
|
||||
~~~
|
||||
|
||||
Save the script.
|
||||
Make it executable.
|
||||
|
||||
sudo chmod +x /rw/config/vpn/qubes-vpn-handler.sh
|
||||
|
||||
4. Configure client to use the DNS handling script. Using openvpn as an example, edit the config.
|
||||
|
||||
sudo nano /rw/config/vpn/openvpn-client.ovpn
|
||||
|
||||
Add the following.
|
||||
|
||||
script-security 2
|
||||
up 'qubes-vpn-handler.sh up'
|
||||
down 'qubes-vpn-handler.sh down'
|
||||
|
||||
Remove other instances of lines starting with `script-security`, `up` or `down` should there be any others.
|
||||
Save the script.
|
||||
**Restart the client and test the connection again** ...this time from an AppVM!
|
||||
|
||||
5. Set up iptables anti-leak rules.
|
||||
Edit the firewall script.
|
||||
|
||||
sudo nano /rw/config/qubes-firewall-user-script
|
||||
|
||||
Clear out the existing lines and add:
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
# Block forwarding of connections through upstream network device
|
||||
# (in case the vpn tunnel breaks):
|
||||
iptables -I FORWARD -o eth0 -j DROP
|
||||
iptables -I FORWARD -i eth0 -j DROP
|
||||
|
||||
# Block all outgoing traffic
|
||||
iptables -P OUTPUT DROP
|
||||
iptables -F OUTPUT
|
||||
iptables -I OUTPUT -o lo -j ACCEPT
|
||||
|
||||
# Add the `qvpn` group to system, if it doesn't already exist
|
||||
if ! grep -q "^qvpn:" /etc/group ; then
|
||||
groupadd -rf qvpn
|
||||
sync
|
||||
fi
|
||||
sleep 2s
|
||||
fi
|
||||
sleep 2s
|
||||
|
||||
# Allow traffic from the `qvpn` group to the uplink interface (eth0);
|
||||
# Our VPN client will run with group `qvpn`.
|
||||
iptables -I OUTPUT -p all -o eth0 -m owner --gid-owner qvpn -j ACCEPT
|
||||
~~~
|
||||
|
||||
# Allow traffic from the `qvpn` group to the uplink interface (eth0);
|
||||
# Our VPN client will run with group `qvpn`.
|
||||
iptables -I OUTPUT -p all -o eth0 -m owner --gid-owner qvpn -j ACCEPT
|
||||
~~~
|
||||
Save the script.
|
||||
Make it executable.
|
||||
|
||||
Now save the script and make it executable:
|
||||
`sudo chmod +x /rw/config/qubes-firewall-user-script`
|
||||
sudo chmod +x /rw/config/qubes-firewall-user-script
|
||||
|
||||
5. Set up the VPN's autostart.
|
||||
5. Set up the VPN's autostart.
|
||||
|
||||
Use `sudo nano /rw/config/rc.local` to clear out the existing lines and add:
|
||||
sudo nano /rw/config/rc.local
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
VPN_CLIENT='openvpn'
|
||||
VPN_OPTIONS='--cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon'
|
||||
|
||||
su - -c 'notify-send "$(hostname): Starting $VPN_CLIENT..." --icon=network-idle' user
|
||||
groupadd -rf qvpn ; sleep 2s
|
||||
sg qvpn -c "$VPN_CLIENT $VPN_OPTIONS"
|
||||
~~~
|
||||
|
||||
Change the `VPN_CLIENT` and `VPN_OPTIONS` variables to match your VPN software.
|
||||
Clear out the existing lines and add:
|
||||
|
||||
~~~
|
||||
#!/bin/bash
|
||||
VPN_CLIENT='openvpn'
|
||||
VPN_OPTIONS='--cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon'
|
||||
|
||||
su - -c 'notify-send "$(hostname): Starting $VPN_CLIENT..." --icon=network-idle' user
|
||||
groupadd -rf qvpn ; sleep 2s
|
||||
sg qvpn -c "$VPN_CLIENT $VPN_OPTIONS"
|
||||
~~~
|
||||
|
||||
If you are using anything other than OpenVPN, change the `VPN_CLIENT` and `VPN_OPTIONS` variables to match your VPN software.
|
||||
Save the script.
|
||||
Make it executable.
|
||||
|
||||
sudo chmod +x /rw/config/rc.local`
|
||||
|
||||
6. Restart the new VM!
|
||||
The link should then be established automatically with a popup notification to that effect.
|
||||
|
||||
Now save the script and make it executable:
|
||||
`sudo chmod +x /rw/config/rc.local`
|
||||
|
||||
6. Restart the new VM! The link should then be established automatically with a popup notification to that effect.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
@ -202,14 +268,13 @@ Configure your AppVMs to use the VPN VM as a NetVM...
|
|||
|
||||

|
||||
|
||||
|
||||
If you want to be able to use the [Qubes firewall](/doc/firewall), create a new FirewallVM (as a ProxyVM) and set it to use the VPN VM as its NetVM.
|
||||
Then, configure AppVMs to use your new FirewallVM as their NetVM.
|
||||
|
||||
If you want to update your TemplateVMs through the VPN, enable the `qubes-updates-proxy` service in your new FirewallVM.
|
||||
You can do this in the Services tab in Qubes VM Manager or on the command-line:
|
||||
|
||||
$ qvm-service -e <name> qubes-updates-proxy
|
||||
qvm-service -e <name> qubes-updates-proxy
|
||||
|
||||
Then, configure your templates to use your new FirewallVM as their NetVM.
|
||||
|
||||
|
|
40
configuration/w3m.md
Normal file
40
configuration/w3m.md
Normal file
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Reducing the fingerprint of the text-based web browser w3m
|
||||
permalink: /doc/w3m/
|
||||
redirect_from:
|
||||
- /en/doc/mutt/
|
||||
- /doc/W3m/
|
||||
- /wiki/W3m/
|
||||
---
|
||||
|
||||
Reducing the fingerprint of the text-based web browser w3m
|
||||
====
|
||||
|
||||
TL;DR: You can reduce the amount of information w3m gives about itself and the environment it is running in (and, by extension, you). **It will not make you anonymous; your fingerprint will still be unique.** But it may improve your privacy.
|
||||
|
||||
[w3m](http://w3m.sourceforge.net/) 'is a text-based web browser as well as a pager like `more` or `less`. With w3m you can browse web pages through a terminal emulator window (xterm, rxvt or something like that). Moreover, w3m can be used as a text formatting tool which typesets HTML into plain text.'
|
||||
|
||||
You can reduce the [browser fingerprint](https://panopticlick.eff.org/about#browser-fingerprinting) by applying the following changes to `~/.w3m/config` in any AppVM you want to use w3m in. (If you have not run w3m yet, you might need to copy the config file from elsewhere.) You can also apply the same changes to `/etc/w3m/config` in the relevant TemplateVM(s) to have them apply to multiple AppVMs; but make sure they are not reversed by the contents of `~/.w3m/config` in any of the AppVMs. (w3m reads `~/.w3m/config` after `/etc/w3m/config`).
|
||||
|
||||
* Set `user_agent` to `user_agent Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0`.
|
||||
|
||||
By default w3m identifies itself as `w3m/` + version number. The user agent `Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0` is the most common and the one used by the Tor Browser Bundle (TBB). One in fourteen browsers fingerprinted by Panopticlick has this value.
|
||||
|
||||
* Make w3m use the same HTTP_ACCEPT headers the TBB by adding the following lines at the end of the file:
|
||||
|
||||
accept_language en-US,en;q=0.5
|
||||
accept_encoding gzip, deflate
|
||||
accept_media text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
|
||||
|
||||
These changes will hide your computer's locale and some other information that may or may not be unique to the VM in which it is running. With the modifications above w3m will have the same headers as about one in fifteen browsers fingerprinted by Panopticlick.
|
||||
|
||||
Testing these settings on <https://browserprint.info> returns a fingerprint that is distinguishable from that of the TBB (with JavaScript disabled) only by 'Screen Size (CSS)' and 'Browser supports HSTS?'.\* (<https://panopticlick.eff.org> does not work with w3m.) Due to the low number of w3m users it is highly likely that you will have an unique browser fingerprint among the visitors of a website using somewhat sophisticated browser fingerprinting technology. But at least your browser fingerprint will not reveal your computer's locale settings or other specifics about it in the HTTP_ACCEPT headers. And while it may be inferred from your fingerprint that you use w3m, it is not be explicitly stated in the User-Agent header.
|
||||
|
||||
**Reminder: Do not rely on these settings for anonymity. Using w3m is all but guaranteed to make you stand out in the crowd.**
|
||||
|
||||
PS: You still need to delete cookies manually (`~/.w3m/cookie`) if you are not running w3m in a DispVM anyway. If you set w3m to not accept cookies, its fingerprint will change. (You can configure w3m to not use store cookies or accept new ones (or both), but the setting `use_cookie` seems to really mean `accept_cookie` and vice-versa, so maybe it is best to delete them manually for now.)
|
||||
|
||||
* * *
|
||||
|
||||
\* Does someone know how to fix this?
|
Loading…
Add table
Add a link
Reference in a new issue