Merge branch 'edit' of git://github.com/clayt0nk/qubes-doc into clayt0nk-edit

This commit is contained in:
Andrew David Wong 2016-07-21 15:03:59 -07:00
commit 3c8bc8857f
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
3 changed files with 54 additions and 19 deletions

View File

@ -12,9 +12,13 @@ redirect_from:
Qubes specific VM config files
==============================
Those files are placed in /rw, which survives VM restart, so can be used to customize single VM (not all VMs based on the same template).
Those files are placed in /rw, which survives VM restart, so can be
used to customize single VM (not all VMs based on the same template).
The scripts here all run as root.
- `/rw/config/rc.local` - script run at VM startup. Good place to change some service settings, replace config files with its copy stored in /rw/config etc. Example usage:
- `/rw/config/rc.local` - script run at VM startup. Good place to
change some service settings, replace config files with its copy stored
in /rw/config etc. Example usage:
~~~
# Store bluetooth keys in /rw to keep them across VM restarts
@ -22,16 +26,26 @@ Those files are placed in /rw, which survives VM restart, so can be used to cust
ln -s /rw/config/var-lib-bluetooth /var/lib/bluetooth
~~~
- `/rw/config/qubes-ip-change-hook` - script run in NetVM after external IP change (or connection to the network)
- `/rw/config/qubes-firewall-user-script` - script run in ProxyVM after firewall update. Good place to write own custom firewall rules
- `/rw/config/suspend-module-blacklist` - list of modules (one per line) to be unloaded before system going to sleep. The file is used only in VM with some PCI devices attached. Supposed to be used for problematic device drivers.
- `/rw/config/qubes-ip-change-hook` - script run in NetVM after
external IP change (or connection to the network)
- `/rw/config/qubes-firewall-user-script` - script run in ProxyVM
after each firewall update. Good place to write own custom firewall
rules
- `/rw/config/suspend-module-blacklist` - list of modules (one per
line) to be unloaded before system going to sleep. The file is used
only in VM with some PCI devices attached. Supposed to be used for
problematic device drivers.
Note that scripts need to be executable (chmod +x) to be used.
GUI and audio configuration in dom0
===================================
GUI configuration file `/etc/qubes/guid.conf` in one of few not managed by qubes-prefs nor Qubes Manager tool. Sample config (included in default installation):
GUI configuration file `/etc/qubes/guid.conf` in one of few not managed
by qubes-prefs nor Qubes Manager tool. Sample config (included in
default installation):
~~~
# Sample configuration file for Qubes GUI daemon
@ -61,9 +75,19 @@ VM: {
Currently supported settings:
- `allow_fullscreen` - allow VM to request its windows to go fullscreen (without any colorful frame). Regardless of this setting, you can also set window fullscreen using trusted window manager settings (right click on title bar).
- `allow_utf8_titles` - allow to use UTF-8 in window titles, otherwise non-ASCII characters are replaced by underscore.
- `secure_copy_sequence` and `secure_paste_sequence` - key sequences used to trigger secure copy and paste
- `windows_count_limit` - limit on concurrent windows count.
- `audio_low_latency` - force low-latency audio mode (about 40ms compared to 200-500ms by default). Note that this will cause much higher CPU usage in dom0.
- `allow_fullscreen` - allow VM to request its windows to go
fullscreen (without any colorful frame). Regardless of this setting,
you can also set window fullscreen using trusted window manager
settings (right click on title bar).
- `allow_utf8_titles` - allow to use UTF-8 in window titles,
otherwise non-ASCII characters are replaced by underscore.
- `secure_copy_sequence` and `secure_paste_sequence` - key sequences
used to trigger secure copy and paste
- `windows_count_limit` - limit on concurrent windows count.
- `audio_low_latency` - force low-latency audio mode (about 40ms
compared to 200-500ms by default). Note that this will cause much
higher CPU usage in dom0.

View File

@ -162,7 +162,7 @@ Setup
to restart all proxy processes.
7. To make sure that the proxy is started automatically when the AppVM
starts change `/rw/config/qubes_firewall_user_script` to include the
starts change `/rw/config/qubes-firewall-user-script` to include the
following line:
/rw/config/tinyproxy/proxyctl.py update
@ -174,8 +174,8 @@ Setup
Make sure that the script is owned by root and executable:
sudo chown root:root /rw/config/qubes_firewall_user_script
sudo chmod 755 /rw/config/qubes_firewall_user_script
sudo chown root:root /rw/config/qubes-firewall-user-script
sudo chmod 755 /rw/config/qubes-firewall-user-script
8. In Qubes VM manager adjust Firewall rules for each AppVM with a
proxy. In a typical case when only HTTP proxy should be used for

View File

@ -86,7 +86,7 @@ sudo iptables -I FORWARD 2 -s <IP address of A> -d <IP address of B> -j ACCEPT
issues from VM A. Note however, that this doesn't allow you to reach A from
B -- for this you would need another rule, with A and B addresses swapped.
* If everything works as expected, then the above iptables rule(s) should be
written into firewall VM's `qubes_firewall_user_script` script which is run
written into firewall VM's `qubes-firewall-user-script` script which is run
on every firewall update. This is necessary, because Qubes orders every
firewall VM to update all the rules whenever new VM is started in the system.
If we didn't enter our rules into this "hook" script, then shortly our custom
@ -97,8 +97,8 @@ sudo iptables -I FORWARD 2 -s <IP address of A> -d <IP address of B> -j ACCEPT
~~~
[user@firewallvm ~]$ sudo bash
[root@firewallvm user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes_firewall_user_script
[root@firewallvm user]# chmod +x /rw/config/qubes_firewall_user_script
[root@firewallvm user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes-firewall-user-script
[root@firewallvm user]# chmod +x /rw/config/qubes-firewall-user-script
~~~
Port forwarding to a VM from the outside world
@ -235,7 +235,7 @@ the service
remove the ` -s 192.168.0.1/24 `
Once you have confirmed that the counters increase, store these command in
'/rw/config/qubes_firewall_user_script'
'/rw/config/qubes-firewall-user-script'
~~~
#!/bin/sh
@ -284,7 +284,7 @@ fi
Finally make this file executable (so it runs at every Firewall VM update)
~~~
sudo chmod +x /rw/config/qubes_firewall_user_script
sudo chmod +x /rw/config/qubes-firewall-user-script
~~~
**3. Allow packets into the VM to reach the service**
@ -315,3 +315,14 @@ fi
This time testing should allow connectivity to the service as long as the
service is up :-)
Where to put firewall rules
---------------------------
Implicit in the above example [scripts](/doc/config-files/), but worth
calling attention to: for all VMs EXCEPT proxy VMs, iptables commands
should be added to the '/rw/config/rc.local' script. For proxy VMs
(sys-firewall inclusive) iptables commands should be added to
'/rw/config/qubes-firewall-user-script'. This is because a proxy VM is
constantly adjusting it's firewall, and therefore initial settings from
rc.local do not persist.