Qubes-Whonix Development / Qubes Integration

Patrick · April 7, 2024, 7:16am

New Templates worked good. Migrated to Qubes community stable repository.

Patrick · April 9, 2024, 7:35am

github.com/QubesOS/qubes-core-agent-linux

Comment by adrelanos - Tell dom0 about basic distribution metadata

QubesOS:main ← marmarek:distro-metadata

> I can do "Debain version + 5" if you prefer this way. Yes, please. > But… I'm mostly after EOL date here in practice. It doesn't need to be set if not known, but it would be nice to have it set once known (which IIUC is known when the next Whonix version is released). Ok. So you're getting `SUPPORT_END` or `ID` (for example `debian`) from file `/etc/os-release`. In case of Debian / Ubuntu the format is: `/usr/share/distro-info/$distro.csv` For example: `/usr/share/distro-info/debian.csv` I guess to keep things simple, standardized, best would be if there was also: * `/usr/share/distro-info/kicksecure.csv` * `/usr/share/distro-info/whonix.csv` or just one: * `/usr/share/distro-info/derivative.csv` * In practice will be the same. Then only 1 file to maintain. * Or whonix.csv could be a symlink to kicksecure.csv. ? Are there any other distributions / derivatives providing something like `/etc/os-release` or `/usr/share/distro-info/$distro.csv`? But I think customization of `/etc/os-release` could lead to more issues than benefits. So let's keep it unmodified as is. Therefore I suggest a simple logic... ``` if [ -f "/usr/share/distro-info/derivative.csv" ]; then eol=$(grep "^$version," "/usr/share/distro-info/derivative.csv" | cut -f 6 -d ,) fi ``` Then I could ship a simplified file: ``` version,codename,series,created,release,eol,eol-lts,eol-elts ,,,,,2026-06-10,, ``` Maybe ship even exactly that file already because by that date, most likely Debian 12 will be EOL already and newer Whonix version already available? But risky if it takes longer for any reason. (Debian delayed, Whonix delayed) And then forgotten to update that file. So I guess better not.

Patrick · April 21, 2024, 4:33pm

Patrick · May 28, 2024, 6:26pm

github.com/QubesOS/qubes-issues

add IPv6 support to Qubes-Whonix

opened 06:26PM - 28 May 24 UTC

adrelanos

T: enhancement P: default

I am working on adding IPv6 support to Whonix. Some Qubes specific questions... … ``` LOCAL_NET="\ 127.0.0.0/24 \ 10.137.0.0/16 \ 10.138.0.0/16 \ " ``` ``` WORKSTATION_DEST_SOCKSIFIED="\ 10.137.0.0/16 \ 10.138.0.0/16 \ 10.152.152.10 \ " ``` Any IPv6 versions? ---- ``` ## DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK ONCE RESULTED IN KERNEL PANICS #$iptables_cmd -A output -f -j REJECT --reject-with icmp-admin-prohibited $nftables_cmd add rule inet filter output ip frag-off "&" 0x1fff != 0 counter reject ``` Useful for IPv6? What would be the equivalent? ---- ``` for int_if_item in $INT_IF; do ## Redirects traffic destined for 10.137.255.154 to port 8082 (tinyproxy). #$iptables_cmd -t nat -A PR-QBS-SERVICES -d 10.137.255.254/32 -i "$int_if_item" -p tcp -m tcp --dport 8082 -j REDIRECT $nftables_cmd add rule inet nat PR-QBS-SERVICES iifname "$int_if_item" ip daddr 10.137.255.254 tcp dport 8082 counter redirect done ``` Is there an IPv6 equivalent for `10.137.255.254`? ---- ``` if qubes_primary_dns="$(qubesdb-read /qubes-primary-dns 2> /dev/null)"; then #$iptables_cmd -A output -p udp --dport 53 --dst "$qubes_primary_dns" -j ACCEPT $nftables_cmd add rule inet filter output ip daddr "$qubes_primary_dns" udp dport 53 counter accept counter=$((counter + 1)) fi if qubes_secondary_dns="$(qubesdb-read /qubes-secondary-dns 2> /dev/null)"; then #$iptables_cmd -A output -p udp --dport 53 --dst "$qubes_secondary_dns" -j ACCEPT $nftables_cmd add rule inet filter output ip daddr "$qubes_secondary_dns" udp dport 53 counter accept counter=$((counter + 1)) fi ``` `qubesdb-read /qubes-primary-dns` will remain IPv4 only? ---- ``` $nftables_cmd add rule inet filter output skuid "$UPDATESPROXYCHECK_USER" ip daddr 10.137.255.254-10.137.255.254 tcp dport "$qubes_updates_proxy_port" counter accept ``` What range would that be for IPv6?

Patrick · June 2, 2024, 4:14pm

Patrick · June 18, 2024, 3:23pm

Patrick · June 20, 2024, 3:57pm

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-17 4.2.0-202406201508 (r4.2)

opened 03:08PM - 20 Jun 24 UTC

fepitre-bot

r4.2-testing

Template whonix-gateway-17 4.2.0-202406201508 for Qubes OS r4.2, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-gateway-17 4.2.0-202406201508 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-gateway-17 4.2.0-202406201508 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-17 4.2.0-202406201508 (r4.2)

opened 03:43PM - 20 Jun 24 UTC

fepitre-bot

r4.2-building

Template whonix-workstation-17 4.2.0-202406201508 for Qubes OS r4.2, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-workstation-17 4.2.0-202406201508 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-workstation-17 4.2.0-202406201508 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · June 23, 2024, 6:13am

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-17 4.2.0-202406201542 (r4.2)

opened 04:32PM - 20 Jun 24 UTC

fepitre-bot

r4.2-testing

Template whonix-gateway-17 4.2.0-202406201542 for Qubes OS r4.2, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-gateway-17 4.2.0-202406201542 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-gateway-17 4.2.0-202406201542 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-17 4.2.0-202406201542 (r4.2)

opened 05:04PM - 20 Jun 24 UTC

fepitre-bot

r4.2-testing

Template whonix-workstation-17 4.2.0-202406201542 for Qubes OS r4.2, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-workstation-17 4.2.0-202406201542 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-workstation-17 4.2.0-202406201542 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · June 30, 2024, 12:53pm

github.com/QubesOS/qubes-issues

create or fork a Linux distribution for default use by App Qubes for better security

opened 12:52PM - 30 Jun 24 UTC

adrelanos

T: enhancement P: default

### The problem you're addressing (if any) Qubes OS is marketed as "a reasona…bly secure operating system", leading users to expect comprehensive security hardening across all aspects of the system. This includes a hardened default browser and other Template hardening. However, the current default templates, particularly for default App Qubes, often include software with suboptimal security (and privacy) settings. This creates a disconnect between user expectations and the out-of-the-box experience. Here are some examples. Quote [Is there a reason Firefox needs to have vulnerable insecure settings in the templates?](https://forum.qubes-os.org/t/is-there-a-reason-firefox-needs-to-have-vulnerable-insecure-settings-in-the-templates/23566) and [Is Firefox really an appropriate default browser for Qubes?](https://forum.qubes-os.org/t/is-firefox-really-an-appropriate-default-browser-for-qubes/26042): * > Firefox comes configured with worst privacy settings * > When I first installed Qubes and I saw Firefox was preloaded I did assume it would have default security setting to be more secure out of the box due to the nature of the system. It was kind of shock to me that it was just setup like a straight download off Firefox. * > why the hell is Firefox allowed to be the default browser on a privacy/security OS when every time I launch it it wants to call all of its friends back home? Literally all of them, even its grandma. It is currently not possible to address this issue in Debian, Fedora Templates, because of the related Qubes FAQ: [What is Qubes’ attitude toward changing guest distros?](https://www.qubes-os.org/faq/#what-is-qubes-attitude-toward-changing-guest-distros). The policy of respecting distribution policy is in direct conflict with Qubes making changes for customization (selected default installed packages), usability (Qubes tools integrations) and security hardening. Example Qubes tickets which can currently not be implemented because of this policy. * https://github.com/QubesOS/qubes-issues/issues/2238 * https://github.com/QubesOS/qubes-issues/issues/1885 This was confirmed by @marmarek in https://github.com/QubesOS/qubes-issues/issues/8730#issuecomment-1828296135. > As you can see, in both cases we in fact did not include them, and in the first case it's even explicitly discussed if that wouldn't be against what Debian is. Fork in this context only means to have for example a Template based on Qubes Debian template, with a distinct name, where security-hardening by default would be permissible without being in contradicting with respecting upstream Linux distribution policy. No other gigantic steps (such as forking all of Debian archive `packages.debian.org`, re-building all the Debian archive are suggested. ### The solution you'd like * ***A)*** Adopting an existing security-focused Linux distribution as the base if any suitable exists; or * ***B)*** A fork of a base distribution by Qubes for the purpose of security-hardening it by default and use it by default. This new template would: * Have security-optimized default settings for browsers and other key applications. * Minimize autostarting services to reduce attack surface. * Allow Qubes developers to implement security best practices without conflicting with upstream policies. Other alternatives: * ***C)*** Reject use of a security-focused Linux distribution by default (due to lack of resources) and improve Qubes branding to reflect that this is out-of-scope. (non-ideal) * ***D)*** Abolish "respect distribution culture" policy. (non-ideal) ### The value to a user, and who that user might be * Aligns the out-of-the-box Qubes experience with user expectations of a security-focused OS. * Provides better default protection for users who don't customize their templates. ### Completion criteria checklist

Patrick · July 8, 2024, 5:11pm

Patrick · July 13, 2024, 10:47pm

Was uploaded to templates-community (stable) repository.

Patrick · August 25, 2024, 2:38pm

github.com/QubesOS/qubes-issues

`spectre-meltdown-checker` reports `CVE-2018-3639 aka 'Variant 4, speculative store bypass'` / set kernel parameter `spec_store_bypass_disable=on` by default

opened 02:38PM - 25 Aug 24 UTC

adrelanos

T: bug P: default

### Qubes OS release 4.2.2 ### Brief summary CVE-2018-3639 aka 'Variant… 4, speculative store bypass' is being reported by `spectre-meltdown-checker` (#4262) with Qubes dom0 default kernel boot parameters settings (GRUB configuration). ### Steps to reproduce In dom0. sudo qubes-dom0-update spectre-meltdown-checker sudo spectre-meltdown-checker --paranoid ### Expected behavior No such notification about vulnerability. ### Actual behavior ``` CVE-2018-3639 aka 'Variant 4, speculative store bypass' * Mitigated according to the /sys interface: NO (Vulnerable) * Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status) * SSB mitigation is enabled and active: NO > STATUS: VULNERABLE (Your CPU doesn't support SSBD) ``` ### Suggested solution Set kernel parameter `spec_store_bypass_disable=on`. This is how security-misc (#1885) is doing this. file `/etc/default/grub.d/40_cpu_mitigations.cfg`: > GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX spec_store_bypass_disable=on"

Patrick · September 15, 2024, 8:11am

move bind-dirs to its own systemd unit file · Issue #5256 · QubesOS/qubes-issues · GitHub

Patrick · September 20, 2024, 9:36pm

Commented on LUKS dictionary attack protection · Issue #9460 · QubesOS/qubes-issues · GitHub.

Patrick · October 12, 2024, 5:27am

github.com/QubesOS/qubes-issues

stop using deprecated `apt-key` in Qubes builder (`qubes-builder-debian`) (prevents removal from `gnupg` from Debian minimal templates)

opened 05:27AM - 12 Oct 24 UTC

adrelanos

T: bug P: default

### Qubes OS release R4.3 ### Brief summary `apt-key` is deprecated by …upstream, Debian. Quote https://manpages.debian.org/bookworm/apt/apt-key.8.en.html > apt-key - Deprecated APT key management utility `apt-key` is no longer required. This caused the issue of `gnupg` not being removable from Debian minimal template. This is because deprecated `apt-key` makes internally use of `gpg`, has a undeclared dependency on `gnupg`. * https://github.com/QubesOS/qubes-builder-debian/pull/85 * https://github.com/QubesOS/qubes-issues/issues/6566 ### Steps to reproduce See `qubes-builder-debian` uses `apt-key` code search https://github.com/search?q=repo%3AQubesOS%2Fqubes-builder-debian%20apt-key&type=code for evidence. ### Expected behavior Qubes builder not using deprecated tools such as `apt-key`. ### Actual behavior Qubes builder using `apt-key`. ### Additional information `apt-key` is no longer required. There is no need to perform any gpg format conversion anymore. `/usr/share/keyrings` folder nowadays supports: * A) gpg binary format (`.gpg); and, * B) gpg `--armor`ed format (`.asc`). Just place the key there. Using `B)` preferably.

Patrick · October 17, 2024, 7:18am

Selective `sudo` Access Enabling in VMs Without `qubes-core-agent-passwordless-root` via `qvm-service` · Issue #9512 · QubesOS/qubes-issues · GitHub

Patrick · October 22, 2024, 12:23pm

create user `admin` by default and add user `admin` to group `sudo` by default · Issue #9519 · QubesOS/qubes-issues · GitHub

Patrick · November 8, 2024, 11:11am

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-17 4.2.0-202411071837 (r4.2)

opened 06:37PM - 07 Nov 24 UTC

fepitre-bot

r4.2-testing

Template whonix-gateway-17 4.2.0-202411071837 for Qubes OS r4.2, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-gateway-17 4.2.0-202411071837 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-gateway-17 4.2.0-202411071837 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-17 4.2.0-202411071542 (r4.2)

opened 04:24PM - 07 Nov 24 UTC

fepitre-bot

r4.2-testing

Template whonix-workstation-17 4.2.0-202411071542 for Qubes OS r4.2, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-workstation-17 4.2.0-202411071542 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-workstation-17 4.2.0-202411071542 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · November 9, 2024, 6:51am

Debian-based updatevm show "unable to detect release version" warning · Issue #7229 · QubesOS/qubes-issues · GitHub

Patrick · November 19, 2024, 7:08pm

github.com/QubesOS/qubes-issues

Use in-vm kernel for Whonix (and possibly Kicksecure)

opened 04:10PM - 11 Nov 24 UTC

hoppity2

T: bug C: templates C: Whonix P: default affects-4.2 affects-4.3

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release Qubes 4.2 ### Brief summary The added kernel boot parameters from Kicksecure's/Whonix's security-misc don't get added to the kernel upon VM boot. ### Steps to reproduce These can be reproduced in the templates as well as other VMs in general, but I'll just use template VMs here for simplicity. 1. Startup a Whonix GW, Whonix WS and Debian (standard) template. (Assumption all have kernels provided by Dom0.) 2. Notice the kernel boot parameters or lack of boot parameters in `/etc/default/grub.d`, in particular `40_cpu_mitigations.cfg` and `40_kernel_hardening.cfg`. `ls /etc/default/grub.d` 3. Open `sudo journalctl -r` search for the start of the boot in the logs (search for: `Command line:`). 4. Notice the lack of extra kernel boot parameters. 5. Clone the Debian standard template. 6. In the cloned Debian standard template install security-misc from Kicksecure/Whonix. 7. Reboot this template, again still with the Dom0 provided kernel notice again how the parameters listed above are missing. 8. In the cloned Debian standard template settings set it to use the template provided kernel `(provided by qube)`. Apply this. You may need to change the HVM virtualization to get it to boot. 9. Restart the cloned Debian standard template with security misc in. 10. Look for the kernel parameters in journalctl for this boot, notice that the extra kernel params in `/etc/default/grub.d` are present. For example: - Whonix GW: - `Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 clocksource=tsc xen_scrub_pages=0 swiotlb=2048 apparmor=1 security=apparmor` - Whonix WS: - `Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 clocksource=tsc xen_scrub_pages=0 swiotlb=2048 apparmor=1 security=apparmor` - Debian (standard), before security-misc install: - `Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 clocksource=tsc xen_scrub_pages=0 swiotlb=2048 apparmor=1 security=apparmor` - Debian (standard), after security-misc install: - `Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 clocksource=tsc xen_scrub_pages=0 swiotlb=2048 apparmor=1 security=apparmor` - Debian (standard), after security-misc install, after changed to internal template kernel: - `Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-27-amd64 root=/dev/mapper/dmroot ro xen_scrub_pages=0 root=/dev/mapper/dmroot console=tty0 console=hvc0 swiotlb=8192 noresume clocksource=tsc mitigations=auto,nosmt nosmt=force spectre_v2=on spectre_bhi=on spec_store_bypass_disable=on l1tf=full,force mds=full,nosmt tsx=off tsx_async_abort=full,nosmt kvm.nx_huge_pages=force l1d_flush=on mmio_stale_data=full,nosmt retbleed=auto,nosmt gather_data_sampling=force reg_file_data_sampling=on slab_nomerge slab_debug=FZ init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on randomize_kstack_offset=on vsyscall=none debugfs=off kfence.sample_interval=100 vdso32=0 amd_iommu=force_isolation intel_iommu=on iommu=force iommu.passthrough=0 iommu.strict=1 efi=disable_early_pci_dma random.trust_bootloader=off random.trust_cpu=off extra_latent_entropy loglevel=0 quiet` ### Expected behavior If I install security-misc or if it's already installed the kernel boot parameters are applied irrespective if you are using a kernel in the template or one provided by Dom0. ### Actual behavior When using the Dom0 provided kernel in a VM it doesn't apply the security-misc's kernel parameters located in `/etc/default/grub.d`. A workaround for this is to simply copy the boot params into Dom0 and set them with `qvm-prefs [VM NAME] kernelopts "[KERNEL PARAMS]"`. However unfortunately kernelopts can only hold up to a maximum of 512 characters, so there isn't enough characters to fit them all in, for future proofing in the meantime perhaps increase this up to say 5120 characters. ### Other Searched on Qubes issues and Kicksecure security-misc issues, couldn't find a similar issue. ----- Issue title adjusted based on the decision for the solution: https://github.com/QubesOS/qubes-issues/issues/9570#issuecomment-2468865938

github.com/Whonix/qubes-template-whonix

Add template.conf that instructs to use in-vm kernel by default

Whonix:master ← marmarek:in-vm-kernel

opened 02:21PM - 19 Nov 24 UTC

marmarek

+1 -0

Switch Whonix templates to use in-vm kernel. This is done by setting empty value… to the "kernel" property (as opposed to leaving it at default). Fixes QubesOS/qubes-issues#9570 This depends on few other changes (mostly to allow setting this option in template-whonix repo, instead of in builder-debian directly): - https://github.com/QubesOS/qubes-builderv2/pull/158 - https://github.com/QubesOS/qubes-builder-debian/pull/87 - https://github.com/QubesOS/qubes-core-admin/pull/634 (already merged in R4.3, but wants a backport to R4.2) And also, it needs adding "install-kernel" option to the template builder config (as "minimal" templates normally do not include the kernel): https://github.com/QubesOS/qubes-release-configs/pull/13 And some more testing, just in case.