Merge branch 'clayt0nk-edit'

configuration/config-files.md

@@ -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.

configuration/http-filtering-proxy.md

@@ -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

security/qubes-firewall.md

@@ -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,15 @@ 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* ProxyVMs, iptables commands 
+should be added to the `/rw/config/rc.local` script. For ProxyVMs 
+(`sys-firewall` inclusive), iptables commands should be added to 
+`/rw/config/qubes-firewall-user-script`. This is because a ProxyVM is 
+constantly adjusting its firewall, and therefore initial settings from 
+`rc.local` do not persist.
+