Qubes-Whonix Development / Qubes Integration

Patrick · July 20, 2023, 11:55am

Qubes R4.2: The Qubes-Whonix 17 Templates were migrated to qubes-templates-community repository just now.

Patrick · August 6, 2023, 5:35pm

Patrick · August 29, 2023, 8:28pm

github.com/QubesOS/qubes-issues

bind-dirs wrong user / group permissions

opened 08:14PM - 29 Aug 23 UTC

adrelanos

T: bug P: default

### Qubes OS release R4.2 ### Brief summary User / group permissions in… [Qubes `bind-dirs` directory](https://www.qubes-os.org/doc/bind-dirs/) are wrong. ### Steps to reproduce Not sure. Might happen by swapping the the underlying Template of a App Qube for another Template or by restoring a VM using Qubes VM backup (which could be similar to the former). ### Expected behavior Correct user / group permissions. ### Actual behavior In corner cases, wrong user / group permissions. ### Additional information * For tracking purposes: This is not a Whonix specific issue. This is a general issues with Qubes bind-dirs. * Affects Qubes-Whonix: Yes. In corner cases users have to run a [Tor permissions fix](https://www.whonix.org/wiki/Tor#Permissions_Fix) because Tor fails to start due to wrong folder permissions. I was now able to most likely pin this issue to Qubes bind-dirs. The permissions in folder `/rw/bind-dirs` (where the fully-persistent data in App Qube resides) (for example "`/rw/bind-dirs/var/lib/tor`") are wrong to begin with. Therefore bind-dirs will mount it also with the wrong permissions as a follow-up error. Why are the user / group permissions in `/rw/bind-dirs` wrong to begin with? Because while Template A and Template B might use the same user / group names (example: "`debian-tor`"), the user identifier (`UID`) and group identifier (`GID`), which are numeric, are most likely different. Unfortunately, Linux stores UID / GID as number in the filesystem, not as literal names.

Patrick · September 4, 2023, 10:14am

add UpdateVM setting to qubes-vm-settings · Issue #3412 · QubesOS/qubes-issues · GitHub

github.com/QubesOS/qubes-issues

UpdateVM usability issue: renaming sys-net or sys-whonix results in Template upgrades being broken / notify about non-existing UpdatesProxy

opened 10:04AM - 04 Sep 23 UTC

adrelanos

T: bug ux P: default needs diagnosis C: updates affects-4.2

### Qubes OS release R4.2 ### Brief summary After renaming, * `sys-n…et` to `sys-net-customized` or * `sys-whonix` to `sys-whonix-customized-name`, Template upgrades are broken. ### Steps to reproduce 1. rename VMs UpdateVM (sys-net or sys-whonix) to something else 2. try to upgrade a TemplateVM ### Expected behavior Functional upgrades or at least some error message with advice how to fix the issue. ### Actual behavior Broken upgrades. ### Additional Maybe there should be an error popup (or something): * "Attempted to use non-existent UpdatesProxy sys-net." * "Attempted to use non-existent UpdatesProxy sys-whonix." "Check your Qubes UpdatesProxy configuration." Still not terribly useful. Hence I will shortly suggest an alternative in a related ticket: * https://github.com/QubesOS/qubes-issues/issues/3412

Patrick · September 5, 2023, 1:20pm

github.com/QubesOS/qubes-issues

avoid calling it GUI domain a "compromise solution" / clarify passthrough security vs usability feature

opened 01:19PM - 05 Sep 23 UTC

adrelanos

T: bug P: default

Quote https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-soluti…on > The compromise solution This can cause a lot of confusion. I can follow your train of thought in the blog post. 1. best solution - [`GPU passthrough: the perfect-world desktop solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#virtual-server-the-perfect-remote-solution) 2. next best solution - [`Virtual server: the perfect remote solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#gpu-passthrough-the-perfect-world-desktop-solution) 3. third best solution - [`The compromise solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-solution) But this is far too complex for users to property contextualize. The problem is, the word `compromise` (also meaning "I got hacked") is very close to `compromised`. The `compromise` here implies "less secure". And yes, it might be "less secure". The fallacious interpretation is "then better don't use it". Less secure than what? Less secure than not using GUI domain at all? No. What the real ordering from best to worst security is, as far as I understand is the following: 1. best solution - Qubes [`GPU passthrough: the perfect-world desktop solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#virtual-server-the-perfect-remote-solution) 2. next best solution - Qubes [`Virtual server: the perfect remote solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#gpu-passthrough-the-perfect-world-desktop-solution) 3. third best solution - Qubes [`The compromise solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-solution) 4. fourth best solution - Qubes without GUI domain 5. non-Qubes This also seems weird `compromise solution` is used in the following context: Quote https://www.qubes-os.org/doc/gui-domain/ > Here, we describe how to setup sys-gui that we call hybrid mode or referenced as a compromise solution in [GUI domain](https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-solution). The next source of confusion exaggerating this issue is the word `passthrough` which is easily understood and already tagged as a negative word in this context. This is because quote [](https://www.qubes-os.org/doc/how-to-use-pci-devices/). > Attaching a PCI device to a qube has serious security implications. PCI passthrough and GPU passthrough are historically have often been usability features. Not security features. Using PCI passthrough has been used as a compromise to make certain devices work Or GPU passthrough might be useful for graphically intense applications such as gaming. However, using passthrough of devices to a dedicated VMs `sys-gui` / `sys-audio` is a security feature, not a usability feature. Qubes documentation is very technical but it lacks contextualization of the very essentials for laymen. These are easy to add. I can send some pull requests. Instead of `compromise` I would suggest words such as `reasonable` or `feasible`. The `compromise solution` could be renamed to the `hybrid solution`. Please correct me if my understanding is wrong.

Patrick · September 17, 2023, 8:45pm

github.com/QubesOS/qubes-issues

Qubes templates build command gpg issue Signature was created after the --not-after date

opened 08:44PM - 17 Sep 23 UTC

adrelanos

T: bug P: default

quote https://github.com/QubesOS/updates-status/issues/566#issuecomment-17222113…33 @fepitre > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > Build-template r4.2 whonix-gateway-17 202309150833 -----BEGIN PGP SIGNATURE----- > > iQKTBAEBCAB9FiEEbpebKKbzfEO+MK+hy41Qu3e7PEgFAmUEF2tfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZF OTc5QjI4QTZGMzdDNDNCRTMwQUZBMUNCOEQ1MEJCNzdCQjNDNDgACgkQy41Qu3e7 PEgjJw//Vem9ff/a8isIUM37m2MI9SJNzvuK/NDla/ma3r6JnalewKjGLS6zc/Gh 2DXkNhOJgC3RpbwE6vfb2/tbOkNumu5BQ7g4yt+E8ay3qHHIw916RmbDVNdIM3MA uG7o86KUDA3G1ouz0JXFI6yxppMbWFuM7UuQb2Hhji2bVD53Mmx/8OgdK3X52vYN joYptgHwM+LEyZID1xDMK9fMl+OvPAaaOTHx57tg5z8VhBM6JPknTjfZp5m0Qx8p PgJMvmvos/28H5H1QFZkWrY1BGQVpavUqWOAhRev6RpQRyIO1li2Wh9pbLN7LPJO +66RiYLsgGOixVYOJ/QUIwL26NXgZYrpQuzafn2kBZ9LqtD6F9YmNayC9ZO1JiHT 1M9O8Nhd612pyNdRwbeECUITCuqZ3GgLsbWXELxxV/nTkr/vAjLOG3xqOVslnVMc KcQGkqjuSz2n1f5v0hCTMBJ3Ha2V/1pWWt9oX4iQv00Ss03FL33aMMZwiuWLNGcP GtZaFflkykGyL7aO9YXeuxgFc20aDIS3CZZ4HjkPbU8nxQOaQRI4xcEZqkpIT4+z vmjSXXzei6Qhk+0Tn9pA7i3IMLyoUopSuz9aTl9ilB3Hq15KbIi2mjCfcfGo/ASE mU82aGFkAR4aQjvyAMb0gSXP1L175J6GqD23EK76IvQTcpyt3i0= =HoSa -----END PGP SIGNATURE----- > > "Signature by 6E97.....48 was created after the --not-after date." Are you sure you used the key allowed here: https://github.com/QubesOS/qubes-release-configs/blob/main/R4.2/qubes-os-r4.2-templates-community.yml#L99? I didn't touch my gpg config and I don't mix other keys into that VM. So this issue is surprising.