Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-07-28 09:14:36 -04:00
Code Issues Projects Releases Packages Wiki Activity

Merge branch 'master' into device-handling-rework

Browse source
This commit is contained in:
GammaSQ 2019-03-14 23:10:54 +01:00
commit 600dc5db6f
6 changed files with 68 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

12
security/firewall.md
View file

@ -102,18 +102,20 @@ default Qubes installation):
Network service qubes
--------------------------------------
Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, ...) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons. In particular if one wants to ensure proper functioning of the Qubes firewall one should not not tinker with iptables or nftables rules in such qubes.
Qubes does not support running any networking services (e.g. VPN, local DNS server, IPS, ...) directly in a qube that is used to run the Qubes firewall service (usually sys-firewall) for good reasons.
In particular, if one wants to ensure proper functioning of the Qubes firewall, one should not tinker with iptables or nftables rules in such qubes.
Instead, one should deploy a network infrastructure such as
~~~
sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]
~~~
Thereby sys-firewall-1 is only needed if one has client qubes connected there as well or wants to manage the traffic of the local network service qube. The sys-firewall-2 proxy ensures that:
Thereby sys-firewall-1 is only needed if one has client qubes connected there as well or wants to manage the traffic of the local network service qube.
The sys-firewall-2 proxy ensures that:
1. Firewall changes done in the network service qube cannot render the Qubes firewall ineffective.
1. Changes to the Qubes firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in the network service qube.
1. A compromise of the network service qube does not compromise the Qubes firewall.
2. Changes to the Qubes firewall by the Qubes maintainers cannot lead to unwanted information leakage in combination with user rules deployed in the network service qube.
3. A compromise of the network service qube does not compromise the Qubes firewall.
For the VPN service please also have a look at the [VPN documentation](/doc/vpn).
For the VPN service please also look at the [VPN documentation](/doc/vpn).
Enabling networking between two qubes
--------------------------------------

18
security/split-gpg.md
View file

@ -107,7 +107,7 @@ AppVM is named `work-gpg`, but of course it might have any other name.
### Setting up the GPG backend domain ###
Make sure the gpg is installed there and there are some private keys in the
Make sure that gpg is installed there, and there are some private keys in the
keyring, e.g.:
[user@work-gpg ~]$ gpg -K
@ -118,12 +118,18 @@ keyring, e.g.:
ssb 4096R/30498E2A 2012-11-15
(...)
This is pretty much all that is required. However one might also want to modify
the default timeout which tells the backend for how long the user's approval
for key access should be valid (default 5 minutes). This is adjustable via
`QUBES_GPG_AUTOACCEPT` variable. One can override it e.g. in `~/.bash_profile`:
This is pretty much all that is required.
However, you might want to modify the default timeout: this tells the backend for how long the user's approval for key access should be valid.
(The default is 5 minutes.)
You can change this via the `QUBES_GPG_AUTOACCEPT` variable.
You can override it e.g. in `~/.profile`:
[user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.bash_profile
[user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile
Please note that at one time, this parameter was set in ~/.bash_profile.
This will no longer work.
If you have the parameter set in ~/.bash_profile you *must* update your configuration.
Please be aware of the caveat regarding passphrase-protected keys in the
[Current limitations][current-limitations] section.