mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-12-01 17:05:04 -05:00
Correct code-block lexers
Changing `bash` lexer to `console` because it is appropriate most of the time. Then after a manual review, some lexer have been changed. I used `text` each time I was unsure, and for prompt outputs. The page `/developer/building/qubes-iso-building.rst` still need to be reviewed (look for lines starting with `$ #`). I'm not sure about the Windows pages, should we use [doscon](https://pygments.org/docs/lexers/#pygments.lexers.shell.MSDOSSessionLexer) or `powershell`? Is there an appropriate lexer for `guid.conf` content? **Statistics - Before** 870 bash 9 python 9 c 2 yaml **Statistics - After** 684 console 111 text 44 bash 16 yaml 9 systemd 9 c 8 python 4 ini 4 doscon 2 markdown 2 desktop 1 xorg.conf 1 xml+jinja 1 xml 1 kconfig 1 html This suggests that the default lexer should be `console`.
This commit is contained in:
parulin
parent
a252dc4338
commit
4212c5eda8
98 changed files with 1022 additions and 1029 deletions
|
|
@ -23,7 +23,7 @@ Installing
|
|||
|
||||
In Dom0 install ``anti-evil-maid``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dom0-update anti-evil-maid
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ If you are using Qubes 4.0, you can further compartmentalise your CTAP keys by r
|
|||
|
||||
To enable this, create a file in dom0 named ``/etc/qubes/policy.d/30-user-ctapproxy.policy`` with the following content:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
policy.RegisterArgument +u2f.Authenticate sys-usb @anyvm allow target=dom0
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ Non-default USB qube name
|
|||
|
||||
If your USB qube is named differently than ``sys-usb``, then do the following in the appropriate template(s):
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
systemctl enable qubes-ctapproxy@USB_QUBE.service
|
||||
systemctl disable qubes-ctapproxy@sys-usb.service
|
||||
|
|
@ -122,4 +122,4 @@ Template and browser support
|
|||
The large number of possible combinations of template (Fedora 37, 38; Debian 10, 11) and browser (multiple Google Chrome versions, multiple Chromium versions, multiple Firefox versions) made it impractical for us to test every combination that users are likely to attempt with the Qubes CTAP Proxy. In some cases, you may be the first person to try a particular combination. Consequently, (and as with any new feature), users will inevitably encounter bugs. We ask for your patience and understanding in this regard. As always, please :doc:`report any bugs you encounter </introduction/issue-tracking>`.
|
||||
|
||||
.. |Qubes CTAP Proxy diagram| image:: /attachment/doc/ctap.svg
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Instead of using the firewall GUI, you can use the ``qvm-firewall`` command in D
|
|||
|
||||
The firewall rules for each qube are saved in an XML file in that qube’s directory in dom0:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
/var/lib/qubes/appvms/<vm-name>/firewall.xml
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ Reconnecting qubes after a NetVM reboot
|
|||
|
||||
Normally Qubes doesn’t let the user stop a NetVM if there are other qubes running which use it as their own NetVM. But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.x will often automatically repair the connection. If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
qvm-prefs <vm> netvm <netvm>
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ Normally Qubes doesn’t let the user stop a NetVM if there are other qubes runn
|
|||
|
||||
Normally qubes do not connect directly to the actual NetVM (sys-net by default) which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers. In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
qvm-prefs sys-firewall netvm sys-net
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ Qubes does not support running any networking services (e.g. VPN, local DNS ser
|
|||
|
||||
Instead, you should deploy a network infrastructure such as
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo nft add rule ip qubes custom-forward ip saddr <IP address of A> ip daddr <IP address of B> ct state new,established,related counter accept
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo nft add rule qubes custom-input ip saddr <IP address of A> ct state new,established,related counter accept
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ Consider the following example. ``mytcp-service`` qube has a TCP service running
|
|||
|
||||
- In dom0, add the following to ``/etc/qubes/policy.d/30-user-networking.policy``: (it could be ``another-other-name.policy`` – just remember to keep it consistent)
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
qubes.ConnectTCP * untrusted @default allow target=mytcp-service
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ which means to use default local port of ``unstrusted`` as the same of the remot
|
|||
|
||||
Consider now the case where someone prefers to specify the destination qube and use another port in untrusted, for example ``10044``. Instead of previous case, add
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
qubes.ConnectTCP * untrusted mytcp-service allow
|
||||
|
||||
|
|
@ -227,7 +227,7 @@ The service of ``mytcp-service`` running on port ``444`` is now accessible in ``
|
|||
|
||||
One can go further than the previous examples by redirecting different ports to different qubes. For example, let assume that another qube ``mytcp-service-bis`` with a TCP service is running on port ``445``. If someone wants ``untrusted`` to be able to reach this service but port ``445`` is reserved to ``mytcp-service-bis`` then, in dom0, add the following to ``/etc/qubes/policy.d/30-user-networking.policy``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
qubes.ConnectTCP +445 untrusted @default allow target=mytcp-service-bis
|
||||
|
||||
|
|
@ -247,15 +247,15 @@ will restrict the binding to only the corresponding TCP port of ``mytcp-service-
|
|||
|
||||
For creating a permanent port bind between two qubes, ``systemd`` can be used. We use the case of the first example. In ``/rw/config`` (or any place you find suitable) of qube ``untrusted``, create ``my-tcp-service.socket`` with content:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: systemd
|
||||
|
||||
[Unit]
|
||||
Description=my-tcp-service
|
||||
|
||||
|
||||
[Socket]
|
||||
ListenStream=127.0.0.1:444
|
||||
Accept=true
|
||||
|
||||
|
||||
[Install]
|
||||
WantedBy=sockets.target
|
||||
|
||||
|
|
@ -263,11 +263,11 @@ For creating a permanent port bind between two qubes, ``systemd`` can be used. W
|
|||
|
||||
and ``my-tcp-service@.service`` with content:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: systemd
|
||||
|
||||
[Unit]
|
||||
Description=my-tcp-service
|
||||
|
||||
|
||||
[Service]
|
||||
ExecStart=qrexec-client-vm '' qubes.ConnectTCP+444
|
||||
StandardInput=socket
|
||||
|
|
@ -353,7 +353,7 @@ When writing rules in sys-net, you can use ``iif`` or ``iifname``. ``iif`` is fa
|
|||
|
||||
In the sys-net VM’s Terminal, the first step is to define an nftables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
|
||||
|
|
@ -367,7 +367,7 @@ In the sys-net VM’s Terminal, the first step is to define an nftables chain th
|
|||
|
||||
Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-dnat-qubeDEST iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
|
||||
|
||||
|
|
@ -375,7 +375,7 @@ Second step, code a natting firewall rule to route traffic on the outside interf
|
|||
|
||||
Third step, code the appropriate new filtering firewall rule to allow new connections for the service
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
|
||||
|
||||
|
|
@ -389,7 +389,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
|
|||
|
||||
Verify the rules on the sys-net firewall correctly match the packets you want by looking at the counters: check for the counter lines in the chains ``custom-forward`` and ``custom-dnat-qubeDEST``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft list table ip qubes
|
||||
|
||||
|
|
@ -397,12 +397,12 @@ Verify the rules on the sys-net firewall correctly match the packets you want by
|
|||
|
||||
In this example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
chain custom-forward {
|
||||
iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
|
||||
}
|
||||
|
||||
|
||||
chain custom-dnat-qubeDEST {
|
||||
type nat hook prerouting priority filter + 1; policy accept;
|
||||
iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter packets 3 bytes 192 dnat to 10.138.33.59
|
||||
|
|
@ -412,7 +412,7 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
|
|||
|
||||
(Optional) You can send a test packet by trying to connect to the service from an external device using the following command:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
telnet 192.168.x.n 443
|
||||
|
||||
|
|
@ -432,13 +432,13 @@ Content of ``/rw/config/qubes-firewall-user-script`` in ``sys-net``:
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
# create the dnat chain for qubeDEST if it doesn't already exist
|
||||
if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
then
|
||||
# create the dnat rule
|
||||
nft add rule qubes custom-dnat-qubeDEST iifname ens6 saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
|
||||
|
||||
|
||||
# allow forwarded traffic
|
||||
nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
|
||||
fi
|
||||
|
|
@ -451,7 +451,7 @@ For the following example, we use the fact that the interface of sys-firewall fa
|
|||
|
||||
In the sys-firewall Terminal, add a DNAT chain that will contain routing rules:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
|
||||
|
|
@ -459,7 +459,7 @@ In the sys-firewall Terminal, add a DNAT chain that will contain routing rules:
|
|||
|
||||
Second step, code a natting firewall rule to route traffic on the outside interface for the service to the destination qube
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
|
||||
|
||||
|
|
@ -467,7 +467,7 @@ Second step, code a natting firewall rule to route traffic on the outside interf
|
|||
|
||||
Third step, code the appropriate new filtering firewall rule to allow new connections for the service
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
|
||||
|
||||
|
|
@ -491,13 +491,13 @@ Content of ``/rw/config/qubes-firewall-user-script`` in ``sys-firewall``:
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
# create the dnat chain for qubeDEST if it doesn't already exist
|
||||
if nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
then
|
||||
# create the dnat rule
|
||||
nft add rule qubes custom-dnat-qubeDEST iifgroup 1 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
|
||||
|
||||
|
||||
# allow forwarded traffic
|
||||
nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
|
||||
fi
|
||||
|
|
@ -514,7 +514,7 @@ For the following example, we assume that the target VM running the web server h
|
|||
|
||||
The according rule to allow the traffic is:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept
|
||||
|
||||
|
|
@ -547,7 +547,7 @@ An effective console utility to troubleshoot network is `tcpdump <https://www.tc
|
|||
|
||||
For instance, if you want to check if your network interface ``eth0`` is receiving packets on port TCP 443 from the network 192.168.x.y, you can run this command:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
tcpdump -i eth0 -nn dst port 443 and src net 192.168.x.y/24
|
||||
|
||||
|
|
@ -565,7 +565,7 @@ By adding ``flush ruleset`` at the top of the file, you can achieve atomic updat
|
|||
|
||||
You can dump the ruleset in two files using the following command:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft list ruleset | tee nft_backup | tee nft_new_ruleset
|
||||
|
||||
|
|
@ -575,7 +575,7 @@ Then, edit ``nft_new_ruleset``, add ``flush ruleset`` on top and make changes, l
|
|||
|
||||
You can revert to the original ruleset with the following commands:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft flush ruleset && nft -f nft_backup
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Instead of using the firewall GUI, you can use the ``qvm-firewall`` command in D
|
|||
|
||||
The firewall rules for each qube are saved in an XML file in that qube’s directory in dom0:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
/var/lib/qubes/appvms/<vm-name>/firewall.xml
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ Qubes does not support running any networking services (e.g. VPN, local DNS ser
|
|||
|
||||
Instead, you should deploy a network infrastructure such as
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ In order to allow networking between qubes A and B follow these steps:
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo iptables -I FORWARD 2 -s <IP address of A> -d <IP address of B> -j ACCEPT
|
||||
|
||||
|
|
@ -119,7 +119,7 @@ In order to allow networking between qubes A and B follow these steps:
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo iptables -I INPUT -s <IP address of A> -j ACCEPT
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ Consider the following example. ``mytcp-service`` qube has a TCP service running
|
|||
|
||||
- In dom0, add the following to ``/etc/qubes/policy.d/30-user-networking.policy``: (it could be ``another-other-name.policy`` – just remember to keep it consistent)
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
qubes.ConnectTCP * untrusted @default allow target=mytcp-service
|
||||
|
||||
|
|
@ -197,7 +197,7 @@ which means to use default local port of ``unstrusted`` as the same of the remot
|
|||
|
||||
Consider now the case where someone prefers to specify the destination qube and use another port in untrusted, for example ``10044``. Instead of previous case, add
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
qubes.ConnectTCP * untrusted mytcp-service allow
|
||||
|
||||
|
|
@ -217,7 +217,7 @@ The service of ``mytcp-service`` running on port ``444`` is now accessible in ``
|
|||
|
||||
One can go further than the previous examples by redirecting different ports to different qubes. For example, let assume that another qube ``mytcp-service-bis`` with a TCP service is running on port ``445``. If someone wants ``untrusted`` to be able to reach this service but port ``445`` is reserved to ``mytcp-service-bis`` then, in dom0, add the following to ``/etc/qubes/policy.d/30-user-networking.policy``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
qubes.ConnectTCP +445 untrusted @default allow target=mytcp-service-bis
|
||||
|
||||
|
|
@ -237,15 +237,15 @@ will restrict the binding to only the corresponding TCP port of ``mytcp-service-
|
|||
|
||||
For creating a permanent port bind between two qubes, ``systemd`` can be used. We use the case of the first example. In ``/rw/config`` (or any place you find suitable) of qube ``untrusted``, create ``my-tcp-service.socket`` with content:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: systemd
|
||||
|
||||
[Unit]
|
||||
Description=my-tcp-service
|
||||
|
||||
|
||||
[Socket]
|
||||
ListenStream=127.0.0.1:444
|
||||
Accept=true
|
||||
|
||||
|
||||
[Install]
|
||||
WantedBy=sockets.target
|
||||
|
||||
|
|
@ -253,11 +253,11 @@ For creating a permanent port bind between two qubes, ``systemd`` can be used. W
|
|||
|
||||
and ``my-tcp-service@.service`` with content:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: systemd
|
||||
|
||||
[Unit]
|
||||
Description=my-tcp-service
|
||||
|
||||
|
||||
[Service]
|
||||
ExecStart=qrexec-client-vm '' qubes.ConnectTCP+444
|
||||
StandardInput=socket
|
||||
|
|
@ -327,7 +327,7 @@ For the following example, we assume that the physical interface eth0 in sys-net
|
|||
|
||||
In the sys-net VM’s Terminal, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT --to-destination 10.137.1.z
|
||||
|
||||
|
|
@ -335,7 +335,7 @@ In the sys-net VM’s Terminal, code a natting firewall rule to route traffic on
|
|||
|
||||
Code the appropriate new filtering firewall rule to allow new connections for the service
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
|
||||
|
||||
|
|
@ -351,7 +351,7 @@ Code the appropriate new filtering firewall rule to allow new connections for th
|
|||
|
||||
Verify you are cutting through the sys-net VM firewall by looking at its counters (column 2)
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
iptables -t nat -L -v -n
|
||||
iptables -L -v -n
|
||||
|
|
@ -362,7 +362,7 @@ Verify you are cutting through the sys-net VM firewall by looking at its counter
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft list table ip qubes-firewall
|
||||
|
||||
|
|
@ -370,7 +370,7 @@ Verify you are cutting through the sys-net VM firewall by looking at its counter
|
|||
|
||||
Send a test packet by trying to connect to the service from an external device
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
telnet 192.168.x.y 443
|
||||
|
||||
|
|
@ -378,7 +378,7 @@ Send a test packet by trying to connect to the service from an external device
|
|||
|
||||
Once you have confirmed that the counters increase, store these command in ``/rw/config/rc.local`` so they get set on sys-net start-up
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo nano /rw/config/rc.local
|
||||
|
||||
|
|
@ -387,45 +387,45 @@ Once you have confirmed that the counters increase, store these command in ``/rw
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
|
||||
|
||||
####################
|
||||
# My service routing
|
||||
|
||||
|
||||
# Create a new firewall natting chain for my service
|
||||
if iptables -w -t nat -N MY-HTTPS; then
|
||||
|
||||
|
||||
# Add a natting rule if it did not exist (to avoid clutter if script executed multiple times)
|
||||
iptables -w -t nat -A MY-HTTPS -j DNAT --to-destination 10.137.1.z
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
|
||||
|
||||
# If no prerouting rule exist for my service
|
||||
if ! iptables -w -t nat -n -L PREROUTING | grep --quiet MY-HTTPS; then
|
||||
|
||||
|
||||
# add a natting rule for the traffic (same reason)
|
||||
iptables -w -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j MY-HTTPS
|
||||
fi
|
||||
|
||||
|
||||
|
||||
|
||||
######################
|
||||
# My service filtering
|
||||
|
||||
|
||||
# Create a new firewall filtering chain for my service
|
||||
if iptables -w -N MY-HTTPS; then
|
||||
|
||||
|
||||
# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
|
||||
iptables -w -A MY-HTTPS -s 192.168.x.0/24 -j ACCEPT
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
# If no forward rule exist for my service
|
||||
if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
|
||||
|
||||
|
||||
# add a forward rule for the traffic (same reason)
|
||||
iptables -w -I FORWARD 2 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
|
|
@ -438,13 +438,13 @@ Once you have confirmed that the counters increase, store these command in ``/rw
|
|||
|
||||
#############
|
||||
# In Qubes R4
|
||||
|
||||
|
||||
# If not already present
|
||||
if nft -nn list table ip qubes-firewall | grep "tcp dport 443 ct state new"; then
|
||||
|
||||
|
||||
# Add a filtering rule
|
||||
nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
|
|
@ -455,7 +455,7 @@ For the following example, we use the fact that the physical interface of sys-fi
|
|||
|
||||
In the sys-firewall VM’s Terminal, code a natting firewall rule to route traffic on its outside interface for the service to the qube
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j DNAT --to-destination 10.137.0.xx
|
||||
|
||||
|
|
@ -463,7 +463,7 @@ In the sys-firewall VM’s Terminal, code a natting firewall rule to route traff
|
|||
|
||||
Code the appropriate new filtering firewall rule to allow new connections for the service
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
|
||||
|
||||
|
|
@ -475,7 +475,7 @@ Code the appropriate new filtering firewall rule to allow new connections for th
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
|
||||
|
||||
|
|
@ -483,7 +483,7 @@ Code the appropriate new filtering firewall rule to allow new connections for th
|
|||
|
||||
Once you have confirmed that the counters increase, store these command in ``/rw/config/qubes-firewall-user-script``
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo nano /rw/config/qubes-firewall-user-script
|
||||
|
||||
|
|
@ -492,63 +492,63 @@ Once you have confirmed that the counters increase, store these command in ``/rw
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
|
||||
|
||||
####################
|
||||
# My service routing
|
||||
|
||||
|
||||
# Create a new firewall natting chain for my service
|
||||
if iptables -w -t nat -N MY-HTTPS; then
|
||||
|
||||
|
||||
# Add a natting rule if it did not exist (to avoid clutter if script executed multiple times)
|
||||
iptables -w -t nat -A MY-HTTPS -j DNAT --to-destination 10.137.0.xx
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
|
||||
|
||||
# If no prerouting rule exist for my service
|
||||
if ! iptables -w -t nat -n -L PREROUTING | grep --quiet MY-HTTPS; then
|
||||
|
||||
|
||||
# add a natting rule for the traffic (same reason)
|
||||
iptables -w -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j MY-HTTPS
|
||||
fi
|
||||
|
||||
|
||||
|
||||
|
||||
######################
|
||||
# My service filtering
|
||||
|
||||
|
||||
# Create a new firewall filtering chain for my service
|
||||
if iptables -w -N MY-HTTPS; then
|
||||
|
||||
|
||||
# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
|
||||
iptables -w -A MY-HTTPS -s 192.168.x.0/24 -j ACCEPT
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
# If no forward rule exist for my service
|
||||
if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
|
||||
|
||||
|
||||
# add a forward rule for the traffic (same reason)
|
||||
iptables -w -I FORWARD 4 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
################
|
||||
# In Qubes OS R4
|
||||
|
||||
|
||||
# If not already present
|
||||
if ! nft -nn list table ip qubes-firewall | grep "tcp dport 443 ct state new"; then
|
||||
|
||||
|
||||
# Add a filtering rule
|
||||
nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
|
||||
Finally make this file executable (so it runs at every Firewall VM update)
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo chmod +x /rw/config/qubes-firewall-user-script
|
||||
|
||||
|
|
@ -560,7 +560,7 @@ If the service should be available to other VMs on the same system, do not forge
|
|||
|
||||
Here no routing is required, only filtering. Proceed in the same way as above but store the filtering rule in the ``/rw/config/rc.local`` script. For the following example, we assume that the target VM running the web server has the IP address 10.137.0.xx
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo nano /rw/config/rc.local
|
||||
|
||||
|
|
@ -570,21 +570,21 @@ Here no routing is required, only filtering. Proceed in the same way as above bu
|
|||
|
||||
######################
|
||||
# My service filtering
|
||||
|
||||
|
||||
# Create a new firewall filtering chain for my service
|
||||
if iptables -w -N MY-HTTPS; then
|
||||
|
||||
|
||||
# Add a filtering rule if it did not exist (to avoid clutter if script executed multiple times)
|
||||
iptables -w -A MY-HTTPS -j ACCEPT
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
# If no input rule exists for my service
|
||||
if ! iptables -w -n -L INPUT | grep --quiet MY-HTTPS; then
|
||||
|
||||
|
||||
# add a forward rule for the traffic (same reason)
|
||||
iptables -w -I INPUT 5 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j MY-HTTPS
|
||||
|
||||
|
||||
fi
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ As the name implies, this generates authentication code that is time-dependent.
|
|||
|
||||
1. Download ``google-authenticator`` in dom0:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dom0-update google-authenticator
|
||||
|
||||
|
|
@ -33,7 +33,7 @@ As the name implies, this generates authentication code that is time-dependent.
|
|||
|
||||
2. Run google authenticator:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
google-authenticator
|
||||
|
||||
|
|
@ -41,14 +41,14 @@ As the name implies, this generates authentication code that is time-dependent.
|
|||
|
||||
3. Walk through the setup instructions which will also generate your QR code for your auth app of choice:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
|
||||
|
||||
|
||||
Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n)
|
||||
|
||||
|
||||
By default, tokens are good for 30 seconds, and to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n)
|
||||
|
||||
|
||||
If the computer that you are logging into isn’t hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n)
|
||||
|
||||
|
||||
|
|
@ -66,14 +66,14 @@ Now we are going to add the authenticator as a login requirement:
|
|||
2. Edit the custom system authentication template in ``/etc/authselect/custom/mfa/system-auth``.
|
||||
Add the following line right after ``auth required pam_faildelay.so delay=2000000``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
auth required pam_google_authenticator.so
|
||||
|
||||
|
||||
After the change, the top of the file should look like this:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
{imply "with-smartcard" if "with-smartcard-required"}
|
||||
auth required pam_env.so
|
||||
|
|
@ -84,7 +84,7 @@ Now we are going to add the authenticator as a login requirement:
|
|||
|
||||
3. Lastly, activate this authentication method with:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo authselect select custom/mfa
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ The following assumes you haven’t restarted your computer since setting up TOT
|
|||
|
||||
2. Revert to the original policy with:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo authselect select sssd
|
||||
|
||||
|
|
@ -168,7 +168,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo dnf install ykpers
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo apt-get install yubikey-personalization
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
2. Install `qubes-app-yubikey <https://github.com/QubesOS/qubes-app-yubikey>`__ in dom0. This provides the program to authenticate with password and YubiKey / NitroKey3.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dom0-update qubes-yubikey-dom0
|
||||
|
||||
|
|
@ -236,7 +236,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
- Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your USB qube and running the following commands in it:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
AESKEY=$(echo -n "your-20-digit-secret" | base32)
|
||||
nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
|
||||
|
|
@ -281,7 +281,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
- You can calculate your hashed password using the following two commands. First run the following command to store your password in a temporary variable ``password``. (This way your password will not leak to the terminal command history file.)
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
read -r password
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
- Now run the following command to calculate your hashed password.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
|
||||
|
||||
|
|
@ -299,7 +299,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
6. To enable multi-factor authentication for a service, you need to add
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
auth include yubikey
|
||||
|
||||
|
|
@ -337,7 +337,7 @@ Optional: Enforce YubiKey / NitroKey3 Login
|
|||
|
||||
Edit ``/etc/pam.d/yubikey`` (or appropriate file if you are using other screen locker program) and remove ``default=ignore`` so the line looks like this.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
auth [success=done] pam_exec.so expose_authtok quiet /usr/bin/yk-auth
|
||||
|
||||
|
|
@ -353,7 +353,7 @@ In dom0:
|
|||
|
||||
1. First configure the qrexec service. Create ``/etc/qubes-rpc/custom.LockScreen`` with a simple command to lock the screen. In the case of xscreensaver (used in Xfce) it would be:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
DISPLAY=:0 xscreensaver-command -lock
|
||||
|
||||
|
|
@ -361,7 +361,7 @@ In dom0:
|
|||
|
||||
2. Then make ``/etc/qubes-rpc/custom.LockScreen`` executable.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo chmod +x /etc/qubes-rpc/custom.LockScreen
|
||||
|
||||
|
|
@ -369,7 +369,7 @@ In dom0:
|
|||
|
||||
3. Allow your USB VM to call that service. Assuming that it’s named ``sys-usb`` it would require creating ``/etc/qubes-rpc/policy/custom.LockScreen`` with:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
sys-usb dom0 allow
|
||||
|
||||
|
|
@ -381,7 +381,7 @@ In your USB VM:
|
|||
|
||||
1. Create udev hook. Store it in ``/rw/config`` to have it persist across VM restarts. For example name the file ``/rw/config/yubikey.rules``. Add the following line:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
|
||||
|
||||
|
|
@ -398,7 +398,7 @@ In your USB VM:
|
|||
|
||||
3. Then make ``/rw/config/rc.local`` executable.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo chmod +x /rw/config/rc.local
|
||||
|
||||
|
|
@ -406,7 +406,7 @@ In your USB VM:
|
|||
|
||||
4. For changes to take effect, you need to call this script manually for the first time.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo /rw/config/rc.local
|
||||
|
||||
|
|
@ -416,7 +416,7 @@ In your USB VM:
|
|||
|
||||
If you use KDE, the command(s) in first step would be different:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
# In the case of USB VM being autostarted, it will not have direct access to D-Bus
|
||||
# session bus, so find its address manually:
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Configuration
|
|||
|
||||
Create/Edit ``/etc/qubes/policy.d/30-user-gpg2.policy`` in dom0, and add a line like this:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
qubes.Gpg2 + gpg-client-vm @default allow target=gpg-server-vm
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ Create/Edit ``/etc/qubes/policy.d/30-user-gpg2.policy`` in dom0, and add a line
|
|||
|
||||
Import/Generate your secret keys in the server domain. For example:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
gpg-server-vm$ gpg --import /path/to/my/secret-keys-export
|
||||
gpg-server-vm$ gpg --import-ownertrust /path/to/my/ownertrust-export
|
||||
|
|
@ -40,7 +40,7 @@ Import/Generate your secret keys in the server domain. For example:
|
|||
|
||||
or
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
gpg-server-vm$ gpg --gen-key
|
||||
|
||||
|
|
@ -48,21 +48,21 @@ or
|
|||
|
||||
In dom0 enable the ``split-gpg2-client`` service in the client domain, for example via the command-line:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME> split-gpg2-client on
|
||||
|
||||
|
||||
To verify if this was done correctly:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
dom0$ qvm-service <SPLIT_GPG2_CLIENT_DOMAIN_NAME>
|
||||
|
||||
|
||||
Output should be:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
split-gpg2-client on
|
||||
|
||||
|
|
@ -71,12 +71,12 @@ Restart the client domain.
|
|||
|
||||
Export the **public** part of your keys and import them in the client domain. Also import/set proper “ownertrust” values. For example:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
gpg-server-vm$ gpg --export > public-keys-export
|
||||
gpg-server-vm$ gpg --export-ownertrust > ownertrust-export
|
||||
gpg-server-vm$ qvm-copy public-keys-export ownertrust-export
|
||||
|
||||
|
||||
gpg-client-vm$ gpg --import ~/QubesIncoming/gpg-server-vm/public-keys-export
|
||||
gpg-client-vm$ gpg --import-ownertrust ~/QubesIncoming/gpg-server-vm/ownertrust-export
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ Export the **public** part of your keys and import them in the client domain. Al
|
|||
|
||||
This should be enough to have it running:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
gpg-client-vm$ gpg -K
|
||||
/home/user/.gnupg/pubring.kbx
|
||||
|
|
@ -140,4 +140,4 @@ This program is distributed in the hope that it will be useful, but WITHOUT ANY
|
|||
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
|
||||
.. |split-gpg-diagram.png| image:: /attachment/doc/split-gpg-diagram.png
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Split GPG
|
|||
|
||||
|
||||
.. warning::
|
||||
|
||||
|
||||
**Note:** This information concerns split-gpg. The implementation has been updated to provide more features in split-gpg-2. Some incomplete information on split-gpg-2 is available :doc:`here </user/security-in-qubes/split-gpg-2>`.
|
||||
|
||||
Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the “smart card” is played by another Qubes app qube. This way one not-so-trusted domain, e.g. the one where Thunderbird is running, can delegate all crypto operations – such as encryption/decryption and signing – to another, more trusted, network-isolated domain. This way the compromise of your domain where Thunderbird or another client app is running – arguably a not-so-unthinkable scenario – does not allow the attacker to automatically also steal all your keys. (We should make a rather obvious comment here that the so-often-used passphrases on private keys are pretty meaningless because the attacker can easily set up a simple backdoor which would wait until the user enters the passphrase and steal the key then.)
|
||||
|
|
@ -99,7 +99,7 @@ Normally it should be enough to set the ``QUBES_GPG_DOMAIN`` to the GPG backend
|
|||
uid Qubes OS Security Team <security@qubes-os.org>
|
||||
ssb 4096R/30498E2A 2012-11-15
|
||||
(...)
|
||||
|
||||
|
||||
[user@work-email ~]$ qubes-gpg-client secret_message.txt.asc
|
||||
(...)
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ The ``qubes-gpg-client-wrapper`` script sets the ``QUBES_GPG_DOMAIN`` variable a
|
|||
|
||||
Split GPG’s default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in ``dom0`` place the following line at the top of the file ``/etc/qubes-rpc/policy/qubes.Gpg``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
work-email work-gpg allow
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ where ``work-email`` is the Thunderbird + Enigmail app qube and ``work-gpg`` con
|
|||
|
||||
You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append ``default_target=<vmname>`` to ``ask`` in ``/etc/qubes-rpc/policy/qubes.Gpg``. For the examples given on this page:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
@anyvm @anyvm ask default_target=work-gpg
|
||||
|
||||
|
|
@ -232,13 +232,13 @@ Using Git with Split GPG
|
|||
|
||||
Git can be configured to utilize Split GPG, something useful if you would like to contribute to the Qubes OS Project as every commit is required to be signed. The most basic ``~/.gitconfig`` file enabling Split GPG looks something like this.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: ini
|
||||
|
||||
[user]
|
||||
name = <YOUR_NAME>
|
||||
email = <YOUR_EMAIL_ADDRESS>
|
||||
signingKey = <YOUR_KEY_ID>
|
||||
|
||||
|
||||
[gpg]
|
||||
program = qubes-gpg-client-wrapper
|
||||
|
||||
|
|
@ -261,7 +261,7 @@ Your key id is the public id of your signing key, which can be found by running
|
|||
|
||||
To sign commits, you now add the “-S” flag to your commit command, which should prompt for Split GPG usage. If you would like to automatically sign all commits, you can add the following snippet to ``~/.gitconfig``.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: ini
|
||||
|
||||
[commit]
|
||||
gpgSign = true
|
||||
|
|
@ -300,8 +300,8 @@ Setup Description
|
|||
|
||||
In this example, the following keys are stored in the following locations (see below for definitions of these terms):
|
||||
|
||||
.. list-table::
|
||||
:widths: 10 10
|
||||
.. list-table::
|
||||
:widths: 10 10
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
|
|
@ -313,7 +313,7 @@ In this example, the following keys are stored in the following locations (see b
|
|||
- ``work-gpg``
|
||||
* - ``pub``
|
||||
- ``work-email``
|
||||
|
||||
|
||||
|
||||
|
||||
- ``sec`` (master secret key)
|
||||
|
|
@ -395,50 +395,50 @@ Current limitations
|
|||
- The Split GPG client will fail to sign or encrypt if the private key in the GnuPG backend is protected by a passphrase. It will give an ``Inappropriate ioctl for device`` error. Do not set passphrases for the private keys in the GPG backend domain. Doing so won’t provide any extra security anyway, as explained in the introduction and in `using Split GPG with subkeys <#advanced-using-split-gpg-with-subkeys>`__. If you are generating a new key pair, or if you have a private key that already has a passphrase, you can use ``gpg2 --edit-key <key_id>`` then ``passwd`` to set an empty passphrase. Note that ``pinentry`` might show an error when you try to set an empty passphrase, but it will still make the change. (See `this StackExchange answer <https://unix.stackexchange.com/a/379373>`__ for more information.) **Note:** The error shows only if you **do not** have graphical pinentry installed.
|
||||
|
||||
|
||||
.. [1]
|
||||
.. [1]
|
||||
In order to gain access to the ``vault`` VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a :ref:`signed, compromised package which is already installed in the template <user/templates/templates:trusting your templates>` upon which the ``vault`` VM is based.
|
||||
|
||||
.. |split-gpg-diagram.png| image:: /attachment/doc/split-gpg-diagram.png
|
||||
|
||||
|
||||
|
||||
.. |r2-split-gpg-1.png| image:: /attachment/doc/r2-split-gpg-1.png
|
||||
|
||||
|
||||
|
||||
.. |r2-split-gpg-3.png| image:: /attachment/doc/r2-split-gpg-3.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-1.png| image:: /attachment/doc/tb78-1.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-2.png| image:: /attachment/doc/tb78-2.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-3.png| image:: /attachment/doc/tb78-3.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-4.png| image:: /attachment/doc/tb78-4.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-5.png| image:: /attachment/doc/tb78-5.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-6.png| image:: /attachment/doc/tb78-6.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-7.png| image:: /attachment/doc/tb78-7.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-8.png| image:: /attachment/doc/tb78-8.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-9.png| image:: /attachment/doc/tb78-9.png
|
||||
|
||||
|
||||
|
||||
.. |tb78-10.png| image:: /attachment/doc/tb78-10.png
|
||||
|
||||
|
||||
|
||||
.. |tb-enigmail-split-gpg-settings-2.png| image:: /attachment/doc/tb-enigmail-split-gpg-settings-2.png
|
||||
|
||||
|
||||
|
||||
.. |r2-split-gpg-5.png| image:: /attachment/doc/r2-split-gpg-5.png
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@ Passwordless root access in qubes
|
|||
|
||||
The background to passswordless root access is summarised in this statement, that used to be found at ``/etc/sudoers.d/qubes`` in each qube:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
user ALL=(ALL) NOPASSWD: ALL
|
||||
|
||||
|
||||
# WTF?! Have you lost your mind?!
|
||||
#
|
||||
# In Qubes VMs there is no point in isolating the root account from
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue