{{Header}}
{{#seo:
|description=List of actionable items can help to improve security on QubesOS.
|image=Qubeswhonix23324.jpg
}}
{{Title|title=
{{q_project_name_long}} Security
}}
{{Contributor|
|status=stable
|about=About this {{Code2|{{PAGENAME}}}} Page
|difficulty=easy
|contributor=[https://forums.whonix.org/users/torjunkie torjunkie]
|support=[[Support]]
}}
{{intro|
List of actionable items can help to improve security on QubesOS.
}}
[[File:Qubeswhonix23324.jpg|thumb]]
= Introduction =
The following list of actionable items can help to improve security on the Qubes platform, and by extension [[Qubes|{{q_project_name_short}}]] users. It is advised to regularly consult either [https://forum.qubes-os.org Qubes forums] or preferably the JavaScript-free option [https://www.mail-archive.com/qubes-users@googlegroups.com/ The Mail Archive].
Additional channels exist for the latest [https://www.qubes-os.org/news/ security news] and [https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md advice].
= Security Domain =
== GPG and Software Packages ==
* Always keep the system up-to-date in [https://www.qubes-os.org/doc/how-to-install-software-in-dom0/ dom0], [https://www.qubes-os.org/doc/how-to-install-software/ templates and standalones].
** Prefer the Qubes Update tool or its command-line equivalent for updates. [[https://www.qubes-os.org/doc/how-to-update/ Updating Qubes OS]: ]Warning: Updating with direct commands such as qubes-dom0-update, dnf update, and apt update is not recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the Qubes Update tool or its command-line equivalents, as described below. (By contrast, installing packages using direct package manager commands is fine.)
[[https://github.com/QubesOS/qubes-issues/issues/6635 Replace built-in Qube Manager update functionality with the Qubes Update tool]] [It is understood that other mechanisms do not have the same security benefits of Qubes Updater GUI which uses the Salt version for update commands. That is, Qubes repository metadata may not be verified which allows attackers to block (but not modify) packages from being updated. For further information, see: [https://forum.qubes-os.org/t/recommendation-against-qubes-dom0-update-use-qubes-updater-instead/4131 Recommendation against "qubes-dom0-update" (use "Qubes Updater" instead)].]
* Check gpg is enabled in [https://docs.fedoraproject.org/en-US/fedora/f35/system-administrators-guide/package-management/DNF/#sec-Setting_main_Options config files] (gpgcheck=1) if new Fedora repositories are installed.
* New repositories should be considered less trusted -- it is safest to keep them separate from Templates that feed more sensitive VMs.
* [[Verifying_Software_Signatures#Checking_Digital_Fingerprints_of_Signing_Keys|Safely import new signing keys]] by checking it is the same from multiple sources.
* Untrusted or unverifiable programs should be installed in Standalone VMs or less trusted, cloned templates.
== Hardware / Hardware Settings ==
* Enable [https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-d VT-d]/[https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit IOMMU] via BIOS to have [https://en.wikipedia.org/wiki/DMA_attack DMA protection], [[https://www.qubes-os.org/faq/#general--security Qubes FAQ]: ]DMA is mechanism for PCI devices to access system memory (read/write). Without VT-d, any PCI device can access all the memory, regardless to which VM it is assigned (or if it is left in dom0). Most PCI devices allow the driver to request an arbitrary DMA operation (like “put received network packets at this address in memory”, or “get this memory area and send it to the network”). So, without VT-d, it gives unlimited access to the whole system. Now, it is only a matter of knowing where to read/write to take over the system, instead of just crashing. But since you can read the whole memory, it isn’t that hard.
effective network isolation and the ability to assign PCIe devices to a HVM. Check it is running via dom0 (qubes-hcl-report). [The [https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md Qubes wiki] notes: ]If VT-d is not active, attempt to activate it by selecting the VT-d flag within the BIOS settings. If your processor/BIOS does not allow VT-d activation you still enjoy much better security than alternative systems, but you may be vulnerable to DMA attacks. Next time you buy a computer consult our [https://www.qubes-os.org/hcl/ HCL (Hardware Compatibility List)] and possibly contribute to it.
* Ensure [https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_(VT-x) Intel VT-x] or [https://en.wikipedia.org/wiki/X86_virtualization#AMD_virtualization_(AMD-V) AMD-V] is available, since it is required for running HVM domains.
* Prepare and utilize a [https://www.qubes-os.org/doc/how-to-use-usb-devices/ USB qube] to protect against side-channel attacks. [This can be automatically configured in Qubes R4.X releases during installation.] [https://github.com/QubesOS/qubes-issues/files/9110959/Qubes_GSC_Module_new_V1.pdf] [In Qubes: ]Common attack vectors such as network cards and USB controllers are isolated in their own hardware qubes, while their functionality is maintained through secure networking, firewalls and USB device management. ... The connection of an untrusted USB device to the Xen management VM Dom0 is a security risk since the device can attack an arbitrary USB driver, exploit bugs during partition-table-parsing or simply pretend to be a keyboard. The whole USB stack is put to work to parse the data presented by the USB device in order to determine if it is a USB mass storage device, to read its configuration, etc. Manipulation of the USB stack can therefore also be used to attack the integrity of Dom0.
* Use a [https://www.nitrokey.com/ Nitrokey] to enhance the security of Qubes user authentication, mitigate the risk of password snooping and to improve USB keyboard security.
* Prefer Intel Integrated Graphics Processing (IGP) units for greater system stability and security. [Proprietary binary blobs of other GPU manufacturers pose security risks and the available open source drivers are notoriously unstable in Qubes.]
* Ensure computer hardware meets all other [[System_Requirements#{{q_project_name_short}}_System_Requirements|{{q_project_name_short}} requirements]] for the best security, functionality and future compatibility with Qubes 4.X releases. The hardware on which Qubes OS is run MUST support IOMMU-based virtualization. This MUST be enabled in the BIOS of the IT system along with the standard virtualization (Intel VT-x) and AMD virtualization (AMD-V) extensions.
dom0 attacks, advanced users can consider:
** [https://github.com/fepitre/qubes-doc/blob/guivm/user/advanced-topics/guivm.md Configuring (not an official instructions link)] the experimental [https://www.qubes-os.org/news/2020/03/18/gui-domain/ GUI domain]; Very briefly, the GUI domain is a qube separate from dom0 that handles all the display-related tasks and some system management. ... Furthermore, while in theory dom0 is isolated from the outside world, some graphical devices (e.g. displays connected via HDMI or DVI) offer two-way communication, which threatens this isolation and makes it harder to maintain. If a malicious device (rather than the user’s trusted monitor) were to be connected to one of these ports, it could inject data that could be processed inside of dom0. As long as graphical devices are in dom0, they also cannot be safely proxied to other domains. This is because the various solutions to multiplexing access to the GPU at the GPU/driver level (which would expose the “full” GPU to a VM) are orders of magnitude more complex than running display drivers in just one place. We consider this added complexity too risky to put it in dom0. Errors in the drivers could expose dom0 to an attack, and attacks on dom0 are the biggest threat to the Qubes security model.
[Qubes OS forum: [https://forum.qubes-os.org/t/how-to-install-use-sys-gui-collecting-all-related-information/6687 How to install/use sys-gui (collecting all related information)].] and/or
** Setting up an [https://forum.qubes-os.org/t/setting-up-an-audio-vm/5491 AudioVM]. [GitHub: [https://github.com/QubesOS/qubes-issues/issues/1590 AudioVM outside of ]dom0] [Related ]salt code can be found [https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-audio.sls here].
== ISO and Qubes Version ==
* Verify the [https://www.qubes-os.org/security/verifying-signatures/ authenticity and integrity] of the Qubes iso download. [User note: Qubes R4.0 and above provides fully virtualized (HVM or PVH) VMs that have [https://www.qubes-os.org/news/2018/03/15/qsb-37-update/ greater protection] against processor speculative execution bugs like the Meltdown and Spectre attacks, and other exploits. Qubes R3.2 and earlier versions relied on para-virtualized (PV) VMs.] [ For instance, this [https://xenbits.xen.org/xsa/advisory-260.html security bug] allowed an attacker to escape from a PV domain and exploit the ]dom0 hypervisor. It only affected Qubes R3.2, since Qubes R4 [https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-039-2018.txt only runs untrusted code in PVH or HVM domains] by default.
== Protecting User Data and Activities ==
* For maximum physical security of Qubes OS, select the disk encryption option during installation. [Malicious software in one qube trying to use side channel attacks against another running qube.] pause or shut down all VMs except the target VM where sensitive operations are being performed (such as key generation). [In simple terms, trusted, high-value qubes can be exploited if run in parallel with untrusted qubes (because they may have been previously exploited).]
* Do not forget that any files or changes to an App Qube's /home, /usr/local and /rw/config directories will persist across reboots; any sensitive material should be stored safely in non-networked VMs.
* Observe the [https://theinvisiblethings.blogspot.com/2011/05/app-oriented-ui-model-and-its-security.html security context] of colored windows borders in Qubes before running applications or manipulating data.
* If paying in cryptocurrencies:
** Consider utilizing a [https://github.com/Qubes-Community/Contents/blob/master/docs/security/split-bitcoin.md “split” bitcoin wallet] which creates an offline “cold storage” wallet and an online “watching only” wallet. A blanket recommendation is impossible regarding which wallet should be used; see [https://www.whonix.org/wiki/Bitcoin Bitcoin], [[Bitcoin_Core|Bitcoin Core]] and [https://www.whonix.org/wiki/Money Money] for further information.
** Consider using a [[Ledger_Hardware_Wallet|hardware wallet]] which has better security than a software wallet.
* Avoid [https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/multiboot.md dual / multi-boot configurations] in Qubes. The other OS could modify the unprotected /boot partition or firmware to maliciously compromise Qubes and/or spy on user activities.
* Be careful when running command line operations. Refer to a [https://github.com/Jeeppler/qubes-cheatsheet/blob/master/qubes-cheatsheet.md suitable resource first], then proceed.
* Use [https://www.qubes-os.org/doc/split-gpg/ split-GPG] for email to reduce the risk of key theft used for encryption / decryption and signing.
* Do not allow {{q_project_name_short}} or other VMs to [https://www.qubes-os.org/doc/how-to-enter-fullscreen-mode/ completely "own" the full screen]. [Without visible, colored decorations drawn by each VM window, a malicious application might only pretend to release the full screen (while the screen appears normal), or the full desktop may be emulated so users are tricked into entering sensitive information into false "trusted" domains.]
* Disable previews (thumbnails) when using a file manager like Nautilus, as this is a known attack vector.
* If utilizing a SSD, consider setting up a periodic job in dom0 to [https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/disk-trim.md trim the disk] since this aids against local forensics. [This can be configured with either systemd (weekly only) or cron (daily or weekly).] [[https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/disk-trim.md Qubes wiki]: ]TRIM can improve security against local forensics when using SSDs, because with TRIM enabled deleting data (usually) results in the actual data being erased quickly, rather than remaining in unallocated space indefinitely. However deletion is not guaranteed, and can fail to happen without warning for a variety of reasons.
* Use Disposabless if opening documents from external sources (such as mail attachments from unknown sources) as office and graphic formats can be infected with malware. Alternatively, they can be converted to other data formats in a Disposables before they are transferred to a productive environment; for example, using the Convert To Trusted PDF and Convert To Trusted Img functions in Qubes. D:.
** Linux-based AppVMs: use LUKS/dm-crypt encryption for the /rw directory (including /home and /usr/local).
** Do not leave the system unattended while an encrypted AppVM is running.
* To minimize the profiling threat posed by [[Hardware_Threat_Minimization#Speakers|speakers]], advanced Qubes users can disable speaker output for AppVMs by default by either: [https://github.com/QubesOS/qubes-issues/issues/2724]
** Utilizing a [https://github.com/3hhh/qubes-callbackd simple daemon (qubes-callbackd)] to react to Qubes OS events (VM started etc.) with configurable commands; or
** Configuring [https://github.com/3hhh/qubes-terminal-hotkeys/blob/master/util/qubes-pactl hotkeys (via qubes-pactl)] to mute/unmute dom0 and all AppVMs.
* Advanced users can consider:
** Setting up [https://github.com/control-owl/suriGUI Suricata] as an advanced intrusion detection system (IDS) and intrusion prevention system (IPS); see footnotes. [[https://resources.infosecinstitute.com/topic/suricata-what-is-it-and-how-can-we-use-it/ Suricata: What is it and how can we use it - Infosec Resources]] [[https://suricata.io/features/ Features - Suricata]] [[https://forum.qubes-os.org/t/ann-sys-ips/8272 ANN: sys-ips - 4.1 - Qubes OS Forum]]
** [https://docs.pi-hole.net/ Pi-hole] as an additional network-level advertisement and Internet tracking blocking application; see footnotes. [[https://blog.tufarolo.eu/how-to-configure-pihole-in-qubesos-proxyvm/ How to configure PiHole in QubesOS (ProxyVM)]] [https://github.com/92VV3M42d3v8/PiHole/blob/master/PiHole%20Cloudflared] [[https://forum.qubes-os.org/t/pi-hole-as-additional-ad-firewall-and-unbound-dns-within-qubes/926 Pi-hole as additional ad-firewall and (unbound) DNS within Qubes - General Discussion - Qubes OS Forum]] [[https://forum.qubes-os.org/t/pi-hole-configuration-qubes-os-4-1/12627 Pi-hole configuration qubes os 4.1 - User Support - Qubes OS Forum]]
== Template and Other VMs ==
* Never run applications in templates or dom0, except updating tools or editors for configuration purposes (running applications poses security risks).
* Avoid installing additional software in dom0. ... a thorough analysis of the possible consequence for the security of Dom0 MUST be performed. Additional software MUST ONLY be installed in Dom0 if it is absolutely necessary and there is no safe alternative.
sys-firewall. Instead, the dedicated NetVM should be specified as none.
** Any template software installations should only use the dedicated update host, using the predefined proxyVM for updating (usually sys-whonix or sys-firewall). dom0 as quickly as possible after they become available. If certain patches are deemed risky, then first clone the affected template/s and install the patches there to test them for full functionality. sys-net, sys-firewall and sys-usb.
* Do not configure {{project_name_long}} as a [https://www.qubes-os.org/doc/standalones-and-hvms/ Standalone VM]. [Unlike App Qubes where only the ''/rw/'' directories are persistent, Standalone VMs are complete clones of the template which have independent file systems. This means it is more vulnerable to the threat of persistent malware.] [https://forums.whonix.org/t/running-whonix-workstation-as-standalonevm/12008]
* Consider creating separate, specialized [https://www.qubes-os.org/doc/templates/minimal/ minimal Templates] for distinct App Qube clearnet activities (like browsing) to reduce the attack surface. [Qubes developer unman has [https://forum.qubes-os.org/t/what-threats-do-minimal-templates-protect-against/4698 noted]: ]It’s a mistake to think that attacks need be against applications. Every time you install an application, it will bring with it a number of libraries, dependencies and recommends. Use of those libraries from the application may be well controlled, but an attacker may be able to chain and abuse them in unexpected ways. That is increasing the attack surface, and using tuned templates minimizes that risk.
[This also reduces the frequency of updates and the associated threat of broken templates. Further, adversaries that get a toe-hold on a user's system will have less potential software vulnerabilities to exploit/chain.]
* Avoid configuring [https://www.qubes-os.org/doc/firewall/ network traffic between two qubes] for security reasons.
* The firewall VM for AppVMs must be configured to be as restrictive as possible, including which addresses an AppVM can connect to. This includes limited additional rules for incoming connections, if required. none. dom0 user prompt]. [There might be potential attacks against the hypervisor or daemons/backends in ]dom0 that require root access. Qubes founder Joanna Rutkowska initially assessed there was limited benefit from isolating the root account from the user account, because [https://www.qubes-os.org/doc/vm-sudo/#passwordless-root-access-in-VMs all user data is already accessible from the latter]. However, she later changed her opinion on the matter; see [https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 here].
* Consider leveraging the non-persistence of Qubes' templates to [https://github.com/tasket/Qubes-VM-hardening fend off malware] by locking-down, quarantining and checking the contents of ''/rw'' private storage. vm-boot-protect.service:
* Acts at VM startup before private volume /rw mounts
* User: Protect /home desktop & shell startup executables
* Root: Quarantine all /rw configs & scripts, with whitelisting
* Re-deploy custom or default files to /rw on each boot
* SHA256 hash checking against unwanted changes
* Provides rescue shell on error or request
* Works with template-based App Qubes, sys-net and sys-vpn
[Disabling of Qubes' default passwordless-root is also required.]
** vm-boot-protect-root: suitable for service VMs like sys-usb and sys-net, as well as App Qubes such as untrusted, personal, banking, vault and so. [If regular Linux applications like Firefox, Chromium, KeePassXC, office/media applications and Thunderbird are used without tailored Qubes-specific settings in ]/rw, then no configuration should be necessary.
** vm-boot-protect: suitable for virtually any Debian or Fedora VM, such as {{project_name_short}} VMs, Standalone VMs and Disposable VMs.
** Non-Linux VMs are currently unsupported for both modes.
* Consider [https://github.com/rustybird/qubes-split-dm-crypt split dm-crypt] to isolate device-mapper based secondary storage encryption (not the root filesystem) and LUKS header processing to Disposables.
* Consider running sys-net, sys-firewall and sys-usb as [https://www.qubes-os.org/doc/disposable-customization/ Static Disposables].
* Consider setting dom0 and all Templates to update over Tor by configuring this option on Qubes' first boot. [https://github.com/QubesOS/qubes-issues/issues/1159#issuecomment-167432121] [This option has been available since Qubes R3.1 and prevents adversaries from easily learning which packages are installed or updated / upgraded. The ]dom0 UpdateVM can also be changed in Qube Manager Global settings.
* Prevent qubes which normally connect to clearnet from downloading repository metadata; see footnotes. [https://www.mail-archive.com/qubes-users@googlegroups.com/msg27567.html ]It is the qubes that perform update checks and then notify dom0 accordingly. So if you have a qube connected to clearnet it will check over clearnet. You can disable this in clearnet connected qubes - it's the qubes-update-check service. Or you can disable globally in qubes-global-settings.
[This removes any time-based correlation by adversaries, which might otherwise occur when package updates over Tor happen shortly after clearnet repository metadata is downloaded.]
** Disable the "Check for qube updates by default" option in Qube Manager Global settings: Qube Manager → System → Global settings → ''Uncheck'' Check for qube updates by default; and
** Disable the qubes-update-check service for relevant Templates: Qubes Manager → Right-click Template → Qubes settings → Services → ''Uncheck'' qubes-update-check. [Tests have shown that both settings must be disabled to prevent clearnet repository metadata downloads and update notifications.]
* Disable cups in all Templates as well as in Standalones that have been created; see footnotes. [https://github.com/QubesOS/qubes-issues/issues/5179] [In Template / Standalone.
{{CodeSelect|code=
sudo systemctl mask cups
}}
Now cups will no longer needlessly autostart in every VM. If it is necessary to use a dedicated printing VM later on, follow these steps to start cups.
{{CodeSelect|code=
sudo systemctl unmask cups
sudo systemctl start cups
}}
These two commands can probably be automated using ]/etc/rc.local.
* If operating system templates are installed that are not officially supported such as Android or ReactOS, they should be treated as less trusted. No security-critical actions should be performed in them or associated AppVMs, such as file exchange with other VMs.