From 524928b022a1da0f3bec322671f4725c0d5117f9 Mon Sep 17 00:00:00 2001 From: qubedmaiska Date: Tue, 3 Jun 2025 13:51:29 -0400 Subject: [PATCH] pre-final fixes --- developer/services/qrexec-internals.md | 2 +- introduction/faq.md | 2 +- introduction/getting-started.md | 2 +- user/advanced-topics/salt.md | 2 +- .../install-security.md | 2 +- .../upgrade/2.md | 8 ++++---- .../upgrade/2b1.md | 4 ++-- .../upgrade/2b2.md | 2 +- .../upgrade/3_0.md | 2 +- .../upgrade/3_2.md | 10 +++++----- .../certified-hardware/certified-hardware.md | 2 +- .../hardware/certified-hardware/nitropc-pro.md | 4 ++-- .../novacustom-nv41-series.md | 4 ++++ .../how-to-organize-your-qubes.md | 2 +- user/security-in-qubes/anti-evil-maid.md | 2 +- user/security-in-qubes/firewall.md | 2 +- user/security-in-qubes/firewall_4.1.md | 13 ++++--------- user/security-in-qubes/mfa.md | 5 +++-- user/security-in-qubes/split-gpg-2.md | 2 +- user/security-in-qubes/split-gpg.md | 18 +++++++++--------- 20 files changed, 45 insertions(+), 45 deletions(-) diff --git a/developer/services/qrexec-internals.md b/developer/services/qrexec-internals.md index e131b473..1888e0e6 100644 --- a/developer/services/qrexec-internals.md +++ b/developer/services/qrexec-internals.md @@ -124,7 +124,7 @@ Details of all possible use cases and the messages involved are described below. - (If `local_program` is set, `qrexec-client` executes it and uses that child's stdin/stdout in place of its own when exchanging data with `qrexec-agent` later.) - - `qrexec-client` translates that request into a `MSG_EXEC_CMDLINE` message sent to `qrexec-daemon`, with `connect_domain` set to 0 (connect to **dom0**) and `connect_port also set to 0 (allocate a port). + - `qrexec-client` translates that request into a `MSG_EXEC_CMDLINE` message sent to `qrexec-daemon`, with `connect_domain` set to 0 (connect to **dom0**) and `connect_port` also set to 0 (allocate a port). - **dom0**: `qrexec-daemon` allocates a free port (in this case 513), and sends a `MSG_EXEC_CMDLINE` back to the client with connection parameters (**domX** and 513) and with command field empty. diff --git a/introduction/faq.md b/introduction/faq.md index de159ce5..49ddeeb1 100644 --- a/introduction/faq.md +++ b/introduction/faq.md @@ -190,7 +190,7 @@ By default, Qubes OS uses [LUKS](https://en.wikipedia.org/wiki/Linux_Unified_Key ### What do all these terms mean? -All Qubes-specific terms are defined in the [glossary](/doc/glossary/) +All Qubes-specific terms are defined in the [glossary](/doc/glossary/). ### Does Qubes run every app in a separate VM? diff --git a/introduction/getting-started.md b/introduction/getting-started.md index 3f02e0fa..3c98450e 100644 --- a/introduction/getting-started.md +++ b/introduction/getting-started.md @@ -149,7 +149,7 @@ The default terminal emulator in Qubes is Xfce Terminal. Opening a terminal emulator in dom0 can be done in several ways: - Go to the App Menu, click on the Settings icon, choose Other from the drop-down menu, and select **Xfce Terminal Emulator** at the bottom. -- Press `Alt`+`F3` and search for `xfce terminal`. +- Press `Alt` + `F3` and search for `xfce terminal`. - Right-click on the desktop and select **Open Terminal Here**. Various command-line tools are described as part of this guide, and the whole reference can be found [here](/doc/tools/). diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md index 1b0767f7..3e7b1bc3 100644 --- a/user/advanced-topics/salt.md +++ b/user/advanced-topics/salt.md @@ -600,8 +600,8 @@ If the log does not contain useful information: $ export PATH="/usr/lib/qubes-vm-connector/ssh-wrapper:$PATH" $ salt-ssh "$target_vm" $salt_command ``` - Adjust $target_vm (VM_NAME) and $salt_command (state.apply). + 6. Execute them, fix problems, repeat. ## Known Pitfalls diff --git a/user/downloading-installing-upgrading/install-security.md b/user/downloading-installing-upgrading/install-security.md index 6a4920c2..a113fb5e 100644 --- a/user/downloading-installing-upgrading/install-security.md +++ b/user/downloading-installing-upgrading/install-security.md @@ -51,7 +51,7 @@ Cons: (If the drive is mounted to a compromised machine, the ISO could be maliciously altered after it has been written to the drive.) * Untrustworthy firmware. (Firmware can be malicious even if the drive is new. - Plugging a drive with rewritable firmware into a compromised machine can also [compromise the drive](https://srlabs.de/badusb/). + Plugging a drive with rewritable firmware into a compromised machine can also [compromise the drive](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil). Installing from a compromised drive could compromise even a brand new Qubes installation.) ### Optical discs diff --git a/user/downloading-installing-upgrading/upgrade/2.md b/user/downloading-installing-upgrading/upgrade/2.md index e46f637c..43ebbd3f 100644 --- a/user/downloading-installing-upgrading/upgrade/2.md +++ b/user/downloading-installing-upgrading/upgrade/2.md @@ -34,7 +34,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous 1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole. -1. Install all the updates for Dom0: +2. Install all the updates for Dom0: ~~~ sudo qubes-dom0-update @@ -42,7 +42,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous After this step you should have `qubes-release-2-5` in your Dom0. Important: if you happen to have `qubes-release-2-6*` then you should downgrade to `qubes-release-2-5`! The `qubes-release-2-6*` packages have been uploaded to the testing repos and were kept there for a few hours, until we realized they bring incorrect repo definitions and so we removed them and also have changed the update procedure a bit (simplifying it). -1. Upgrade dom0 to R2: +3. Upgrade dom0 to R2: Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest Qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there. @@ -51,7 +51,7 @@ sudo qubes-dom0-update qubes-dom0-dist-upgrade sudo qubes-dom0-update ~~~ -1. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option. +4. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option. 4a. If you chose not to upgrade your fc18 templates, but instead to download our new fc20-based template you should now be able to do that by simply typing: @@ -59,6 +59,6 @@ sudo qubes-dom0-update sudo qubes-dom0-update qubes-template-fedora-20-x64 ~~~ -1. Reboot the system. +5. Reboot the system. Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that. diff --git a/user/downloading-installing-upgrading/upgrade/2b1.md b/user/downloading-installing-upgrading/upgrade/2b1.md index 0d564fb5..8c1c0fbf 100644 --- a/user/downloading-installing-upgrading/upgrade/2b1.md +++ b/user/downloading-installing-upgrading/upgrade/2b1.md @@ -13,7 +13,7 @@ title: Upgrading to R2B1 **Note: Qubes R2 Beta 1 is no longer supported! Please install or upgrade to a newer Qubes R2.** -**Note: This page is kept for historical reasons only! Do not follow the instructions below'''** +**Note: This page is kept for historical reasons only! Do not follow the instructions below** Existing users of Qubes R1 (but not R1 betas!) can upgrade their systems to the latest R2 beta release by following the procedure below. As usual, it is advisable to backup the system before proceeding with the upgrade @@ -51,7 +51,7 @@ By default, in Qubes R1, there is only one template, however users are free to c - via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key. - via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template). -1. Shut down the VM. +4. Shut down the VM. Upgrade Dom0 ------------ diff --git a/user/downloading-installing-upgrading/upgrade/2b2.md b/user/downloading-installing-upgrading/upgrade/2b2.md index 29020439..727d6d74 100644 --- a/user/downloading-installing-upgrading/upgrade/2b2.md +++ b/user/downloading-installing-upgrading/upgrade/2b2.md @@ -49,7 +49,7 @@ By default, in Qubes R1, there is only one template, however users are free to c - via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key. - via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template). -1. Shut down the VM. +4. Shut down the VM. Installing new template ----------------------- diff --git a/user/downloading-installing-upgrading/upgrade/3_0.md b/user/downloading-installing-upgrading/upgrade/3_0.md index 24f477d4..0cb815b3 100644 --- a/user/downloading-installing-upgrading/upgrade/3_0.md +++ b/user/downloading-installing-upgrading/upgrade/3_0.md @@ -101,7 +101,7 @@ Be sure to do steps described in this section after *all* your template and stan 6. Reboot the system. - It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage. + - It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage. Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that. diff --git a/user/downloading-installing-upgrading/upgrade/3_2.md b/user/downloading-installing-upgrading/upgrade/3_2.md index ed1e9f9e..53c87a89 100644 --- a/user/downloading-installing-upgrading/upgrade/3_2.md +++ b/user/downloading-installing-upgrading/upgrade/3_2.md @@ -29,13 +29,13 @@ by following the procedure below. sudo qubes-dom0-update --releasever=3.2 qubes-release ``` - If you made any manual changes to repository definitions, new definitions + - If you made any manual changes to repository definitions, new definitions will be installed as `/etc/yum.repos.d/qubes-dom0.repo.rpmnew` (you'll see a message about it during package installation). In such a case, you need to manually apply the changes to `/etc/yum.repos.d/qubes-dom0.repo` or simply replace it with .rpmnew file. - If you are using Debian-based VM as UpdateVM (`sys-firewall` by default), + - If you are using Debian-based VM as UpdateVM (`sys-firewall` by default), you need to download few more packages manually, but **do not install them** yet: @@ -60,7 +60,7 @@ by following the procedure below. sudo qubes-dom0-update ``` - You may wish to disable the screensaver "Lock screen" feature for this step, as + - You may wish to disable the screensaver "Lock screen" feature for this step, as during the update XScreensaver may encounter an "Authentication failed" issue, requiring a hard reboot. Alternatively, you may simply move the mouse regularly. @@ -70,7 +70,7 @@ by following the procedure below. 6. Update configuration files. - Some of configuration files were saved with `.rpmnew` extension as the + - Some of configuration files were saved with `.rpmnew` extension as the actual files were modified. During upgrade, you'll see information about such cases, like: @@ -78,7 +78,7 @@ by following the procedure below. warning: /etc/salt/minion.d/f_defaults.conf created as /etc/salt/minion.d/f_defaults.conf.rpmnew ``` - This will happen for every configuration you have modified manually and for + - This will happen for every configuration you have modified manually and for a few that has been modified by Qubes scripts. If you are not sure what to do about them, below is a list of commands to deal with few common cases (either keep the old one, or replace with the new one): diff --git a/user/hardware/certified-hardware/certified-hardware.md b/user/hardware/certified-hardware/certified-hardware.md index e3465e62..83cc9ba6 100644 --- a/user/hardware/certified-hardware/certified-hardware.md +++ b/user/hardware/certified-hardware/certified-hardware.md @@ -32,7 +32,7 @@ The current Qubes-certified models are listed below in reverse chronological ord | [NovaCustom](https://novacustom.com/) | [V56 Series](https://novacustom.com/product/v56-series/) | [Certification details](/doc/certified-hardware/novacustom-v56-series/) | | [Nitrokey](https://www.nitrokey.com/) | [NitroPC Pro 2](https://shop.nitrokey.com/shop/nitropc-pro-2-523) | [Certification details](/doc/certified-hardware/nitropc-pro-2/) | | [Star Labs](https://starlabs.systems/) | [StarBook](https://starlabs.systems/pages/starbook) | [Certification details](/doc/certified-hardware/starlabs-starbook/) | -| [Nitrokey](https://www.nitrokey.com/) | [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) | [Certification details](/doc/certified-hardware/nitropc-pro/) | +| [Nitrokey](https://www.nitrokey.com/) | [NitroPC Pro](https://web.archive.org/web/20231027112856/https://shop.nitrokey.com/shop/product/nitropc-pro-523) | [Certification details](/doc/certified-hardware/nitropc-pro/) | | [NovaCustom](https://novacustom.com/) | [NV41 Series](https://novacustom.com/product/nv41-series/) | [Certification details](/doc/certified-hardware/novacustom-nv41-series/) | | [3mdeb](https://3mdeb.com/) | [Dasharo FidelisGuard Z690](https://web.archive.org/web/20240917145232/https://shop.3mdeb.com/shop/open-source-hardware/dasharo-fidelisguard-z690-qubes-os-certified/) | [Certification details](/doc/certified-hardware/dasharo-fidelisguard-z690/) | | [Nitrokey](https://www.nitrokey.com/) | [NitroPad T430](https://shop.nitrokey.com/shop/product/nitropad-t430-119) | [Certification details](/doc/certified-hardware/nitropad-t430/) | diff --git a/user/hardware/certified-hardware/nitropc-pro.md b/user/hardware/certified-hardware/nitropc-pro.md index 91abff8b..bce50f0c 100644 --- a/user/hardware/certified-hardware/nitropc-pro.md +++ b/user/hardware/certified-hardware/nitropc-pro.md @@ -17,7 +17,7 @@ ref: 356 Note: Only the "Dasharo TianoCore UEFI without Measured Boot, without Nitrokey" firmware option is certified. The "HEADS with Measured Boot, requires Nitrokey!" firmware option is not certified. -The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4. +The [NitroPC Pro](https://web.archive.org/web/20231027112856/https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4. [![Photo of NitroPC Pro](/attachment/posts/nitropc-pro.jpg)](https://shop.nitrokey.com/shop/product/nitropc-pro-523) @@ -40,7 +40,7 @@ The NitroPC Pro also comes with a "Dasharo Entry Subscription," which includes t - Accesses to the latest firmware releases - Exclusive newsletter - Special firmware updates, including early access to updates enhancing privacy, security, performance, and compatibility -- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap)) +- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/archive/dug_2/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap)) - Access to the Dasharo Premier Support invite-only live chat channel on the Matrix network, allowing direct access to the Dasharo Team and fellow subscribers with personalized and priority assistance - Insider's view and influence on the Dasharo feature roadmap for a real impact on Dasharo development - [Dasharo Tools Suite Entry Subscription](https://docs.dasharo.com/osf-trivia-list/dts/#what-is-dasharo-tools-suite-supporters-entrance) keys diff --git a/user/hardware/certified-hardware/novacustom-nv41-series.md b/user/hardware/certified-hardware/novacustom-nv41-series.md index ca7b6745..d4600ad5 100644 --- a/user/hardware/certified-hardware/novacustom-nv41-series.md +++ b/user/hardware/certified-hardware/novacustom-nv41-series.md @@ -16,19 +16,23 @@ The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is [of The following configuration options are certified for Qubes OS Release 4: Processor: + - Intel Core i5-1240P processor - Intel Core i7-1260P processor Memory: + - 2 x 16 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total) - 1 x 32 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total) - 2 x 32 GB Kingston DDR4 SODIMM 3200 MHz (64 GB total) M.2 storage chip: + - Samsung 980 SSD (all capacities) - Samsung 980 Pro SSD (all capacities) Wi-Fi and Bluetooth: + - Intel AX-200/201 Wi-Fi module 2976 Mbps, 802.11ax/Wi-Fi 6 + Bluetooth 5.2 - Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3 - Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0 diff --git a/user/how-to-guides/how-to-organize-your-qubes.md b/user/how-to-guides/how-to-organize-your-qubes.md index 947312b9..780f0664 100644 --- a/user/how-to-guides/how-to-organize-your-qubes.md +++ b/user/how-to-guides/how-to-organize-your-qubes.md @@ -336,7 +336,7 @@ her setup looks like this: reports. - **Two qubes for taxes.** Carol has a [Windows - qube](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows.md) + qube](/doc/templates/windows/) for running her Windows-only tax software. She also has an offline vault where she stores all of her tax-related forms and documents, organized by year. diff --git a/user/security-in-qubes/anti-evil-maid.md b/user/security-in-qubes/anti-evil-maid.md index 0bcf0964..3980b00a 100644 --- a/user/security-in-qubes/anti-evil-maid.md +++ b/user/security-in-qubes/anti-evil-maid.md @@ -43,7 +43,7 @@ Security Considerations However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., [mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class)) directly to dom0. (The other option is to install AEM to an internal disk. However, this carries significant security implications, as explained [here](https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html).) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand. -Given the practical feasibility of attacks like [BadUSB](https://srlabs.de/badusb/) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision. +Given the practical feasibility of attacks like [BadUSB](https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision. New, factory-sealed USB drives cannot simply be assumed to be "clean" (e.g., to have non-malicious microcontroller firmware). Therefore, it is up to each individual Qubes user to evaluate the relative risk of each attack vector against his or her security model. diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md index 478dc981..272eab36 100644 --- a/user/security-in-qubes/firewall.md +++ b/user/security-in-qubes/firewall.md @@ -312,7 +312,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec 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 ``` -- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules +- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules. - If you want to expose the service on multiple interfaces, repeat steps 2 and 3 above, for each interface. Alternatively, you can leave out the interface completely. diff --git a/user/security-in-qubes/firewall_4.1.md b/user/security-in-qubes/firewall_4.1.md index 7c5e2769..7da45432 100644 --- a/user/security-in-qubes/firewall_4.1.md +++ b/user/security-in-qubes/firewall_4.1.md @@ -10,8 +10,7 @@ title: Firewall 4.1 Introduction ---------------------------------- This page explains use of the firewall in Qubes 4.1, using `iptables`. -From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/) - +From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/). Understanding firewalling in Qubes ---------------------------------- @@ -60,14 +59,10 @@ 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.0 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: - -` qvm-prefs netvm ` +If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0: `qvm-prefs netvm ` Normally qubes do not connect directly to the actual NetVM 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): - -` qvm-prefs sys-firewall netvm sys-net ` +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): `qvm-prefs sys-firewall netvm sys-net` Network service qubes --------------------- @@ -90,7 +85,7 @@ The sys-firewall-2 proxy ensures that: If you adopt this model, you should be aware that all traffic will arrive at the `network service qube` appearing to originate from the IP address of `sys-firewall-2`. -For the VPN service please also look at the [VPN documentation](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md). +For the VPN service please also look at the [VPN documentation](https://forum.qubes-os.org/t/configuring-a-proxyvm-vpn-gateway/19061). Enabling networking between two qubes ------------------------------------- diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md index 3c6b4d79..9ea5b532 100644 --- a/user/security-in-qubes/mfa.md +++ b/user/security-in-qubes/mfa.md @@ -46,7 +46,7 @@ and then use it as an additional factor to login to your Qubes system. google-authenticator ``` -3. Walk through the setup instructions 2 which will also generate your QR code for your auth app of choice: +3. Walk through the setup instructions which will also generate your QR code for your auth app of choice: ``` Do you want me to update your “/home/user/.google_authenticator” file (y/n) y @@ -120,7 +120,8 @@ The second option is recovery from a backup. It will work as long as you include The YubiKey / NitroKey3 is a hardware authentication device manufactured by Yubico / NitroKey to protect access to computers, networks, and online services that supports one-time passwords (OTP), public-key cryptography, and authentication, and the -Universal 2nd Factor (U2F) and FIDO2 protocols[1] developed by the FIDO Alliance. +Universal 2nd Factor [(U2F)](https://en.wikipedia.org/wiki/Universal_2nd_Factor) +and FIDO2 protocols developed by the [FIDO Alliance](https://en.wikipedia.org/wiki/FIDO_Alliance). You can use a YubiKey / NitroKey3 to enhance the user authentication in Qubes. The following instructions explain how to setup the YubiKey / NitroKey3 as an *additional* way to login. diff --git a/user/security-in-qubes/split-gpg-2.md b/user/security-in-qubes/split-gpg-2.md index 68cdb3aa..83a36f8d 100644 --- a/user/security-in-qubes/split-gpg-2.md +++ b/user/security-in-qubes/split-gpg-2.md @@ -121,7 +121,7 @@ If you want to generate a key on a smartcard or other hardware token, use `addca ## Advanced usage There are a few option not described in this README. -See the comments in the example (config and the source code)[https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example]. +See the comments in the example [config and the source code](https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example). Similar to a smartcard, split-gpg2 only tries to protect the private key. For advanced usages, consider if a specialized RPC service would be better. diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md index 86966b2f..c19096b1 100644 --- a/user/security-in-qubes/split-gpg.md +++ b/user/security-in-qubes/split-gpg.md @@ -303,7 +303,7 @@ In this example, the following keys are stored in the following locations (see b * `sec` (master secret key) - Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys. + - Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys. This key may be created *without* an expiration date. This is for two reasons. First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below). @@ -312,7 +312,7 @@ In this example, the following keys are stored in the following locations (see b An adversary who does *not* possess the passphrase cannot use the key at all. In either case, an expiration date provides no additional benefit. - By the same token, however, having a passphrase on the key is of little value. + - By the same token, however, having a passphrase on the key is of little value. An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it. An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key. Therefore, using a passphrase at all should be considered optional. @@ -320,40 +320,40 @@ In this example, the following keys are stored in the following locations (see b * `ssb` (secret subkey) - Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**. + - Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**. You may also wish to give these subkeys reasonable expiration dates (e.g., one year). Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires. - On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey. + - On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey. If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails. If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails. - On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them. + - On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them. This can be problematic, since there is no consensus on how expired signatures should be handled. Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys. * `pub` (public key) - This is the complement of the master secret key. + - This is the complement of the master secret key. It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others. * `vault` - This is a network-isolated VM. + - This is a network-isolated VM. The initial master keypair and subkeys are generated in this VM. The master secret key *never* leaves this VM under *any* circumstances. No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances. * `work-gpg` - This is a network-isolated VM. + - This is a network-isolated VM. This VM is used *only* as the GPG backend for `work-email`. The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM. Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances. * `work-email` - This VM has access to the mail server. + - This VM has access to the mail server. It accesses the `work-gpg` VM via the Split GPG protocol. The public key may be stored in this VM so that it can be attached to emails and for other such purposes.