Rootless virtual machines with KVM and QEMU

KVM
101

Yeah you can clone the VMs and work normally.

Not sure what you are referring to, but generally not much of different from before (though the wiki still needs more testings for optional stuff).

102

Do you have a link to a passt apparmor profile that works with kicksecure or whonix VMs?

103

I said we have one? Ubuntu has one.

104

Ubuntu’s breaks passt though, as discussed above.

106

I tried the Debian 13 passt apparmor profile on Arch Linux. The profile work with Whonix KVM

1 Like
107

This is section is not applicable anymore, zulucrypt not installed by default and no sudo on user side, i see it meaningless to keep, any issues to remove it? Mention if there are alternatives to try.

1 Like
108

Might still be useful for people who remove user-sysmaint-split, though in the absence of software that does something like zuluCrypt it does seem kind of useless.

Related:

2 Likes
109

I dont see it a good idea to keep stuff for people who wants to go and do gymnastics with the OS, because if we keep the sudo parts and the split parts and try to keeps them up to date (generally for the wiki not just kvm wiki) the wiki gonna become a garbage text collection instead of useful updated readable trimmed wiki.

Also since KVM default xml is for user level, and wiki have been changed to explain only user level, then anything else the user want to do then yeah bro enjoy it.. but wiki wont spoon feed that.

I will test Cryfs (GUI called SiriKali) to see if its usable with user level only + KVM VMs. If not then this chapter of the wiki is N/A anymore.

1 Like
110

I disagree. Removing user-sysmaint-split isn’t “doing gymnastics with the OS”, it’s a fully supported facet of user-sysmaint-split, to the point where there is even a boot menu entry dedicated to removing the feature so that users can access it as easily as possible and know it’s an option. Much of the wiki and source code is designed to accommodate both kinds of users.

That being said…

I looked a bit closer and it looks like the only reason sudo was needed before was to allow a sandboxed libvirt process access to files owned by the end-user. Now that libvirt is running as the end-user’s account, that shouldn’t be a problem. So maybe the whole discussion about user-sysmaint-split here is moot.

Sounds cool, I see SiriKali is in the Debian repositories. (I would personally prefer something that operated similar to zuluCrypt in that it could work with real LUKS containers, since I trust LUKS to not have fatal flaws more than I trust CryFS, but on the other hand using FUSE is probably a good thing to keep potentially malware-modifiable filesystem structures from being exposed to the kernel. EDIT: Though if one wants to use FUSE to defend the kernel, fuse2fs is a thing…)

1 Like
111

Environment

  • Host: Ubuntu 24.04 (Noble), libvirt 10.0.0, qemu-system-x86_64 (Ubuntu build), passt 0.0~git20240220.1e6f92b-1
    • Guest: Whonix-Gateway 18.2.1.9 (LXQt), official KVM libvirt.xz image, <interface type='user'><backend type='passt'/></interface> as shipped in the template XML
  • Problem

On this host, passt auto-detects the guest-facing subnet from the host’s actual default-route interface (e.g. my LAN’s 192.168.100.0/24), not the legacy 10.0.2.0/24 that Whonix-Gateway’s /etc/network/interfaces.d/30_non-qubes-whonix hardcodes for eth0 (address 10.0.2.15, gateway 10.0.2.2 — the old VirtualBox-NAT-compatible values). Since eth0 is statically configured (DHCP was intentionally removed from the Gateway per the hardening effort referenced in that file), the guest never negotiates anything with passt and keeps using 10.0.2.15/10.0.2.2, which passt doesn’t recognize as “its” subnet. Result: Tor never gets a single byte out (confirmed with ss inside the guest showing endless SYN-SENT to real Tor relays, and tcpdump on the host’s real NIC showing zero packets ever leaving toward those relay IPs).

Attempted workaround

Bypassed libvirt’s automatic passt invocation and ran my own long-lived passt process with explicit --address 10.0.2.15 --netmask 24 --gateway 10.0.2.2 --mac-addr <gateway-mac>, wired to the domain via <qemu:commandline> (-netdev stream,...,addr.path=/tmp/whonix-gw-net0.sock + matching -device virtio-net-pci). This gets the guest and passt talking (no crash, correct DHCP banner printed by passt), but forwarding still doesn’t work — tcpdump on the host confirms passt never sends any of that traffic out to the real internet. It seems passt’s NAT/forwarding logic requires the guest-facing address to correspond to a real host subnet/route, so forcing an arbitrary address via -a/-g/-n doesn’t make it forward for a foreign subnet.

Two related AppArmor bugs found along the way (Ubuntu’s /etc/apparmor.d/abstractions/libvirt-qemu), both worth fixing regardless of the above:

  1. The nested profile passt { ... } block grants /usr/bin/passt r, but not m (mmap) — passt segfaults immediately on start (Child process (passt ...) unexpected fatal signal 11) unless this is changed to /usr/bin/passt rm,.
    1. Even after fixing (1), QEMU’s own (outer) profile has no rule allowing it to connect() to the passt UNIX socket it just spawned — only the nested passt sub-profile can access @{run}/libvirt/qemu/passt/*. Without also adding owner @{run}/libvirt/qemu/passt/* rw, at the top level of the abstraction (outside the nested profile), QEMU’s -netdev stream client connection to passt’s socket is silently denied forever (DENIED operation="connect" ... comm="io-task-worker"), and the Gateway sits with zero traffic indefinitely even though passt itself looks perfectly healthy.
  3. Question

Is there a supported way to tell libvirt to pass -a/-g/-n (or otherwise pin the subnet) to the passt instance it manages for <interface type='user'><backend type='passt'/></interface>? The domain XML schema (domaincommon.rng) only exposes type/tap/vhost/logFile on <backend>, nothing address-related. Absent that, is switching Gateway’s eth0 to DHCP (leaving eth1/internal untouched) considered safe, or does the external-facing address get referenced by the firewall/Tor config the same way the internal /18 does (per Patrick’s reply in the VMware NAT thread)?

Thanks for all the work on Whonix — happy to test patches or provide more logs.

1 Like
112

This looks like a useful bug report, but please note:

1 Like
113

Well glad it worked out, here is the tutorial:

1 Like
114

on point number 6, the command there when i use code select is not working. cc @Patrick.

1 Like
115

The CodeSelect gets confused by the { or something. Using <pre> tags meanwhile. Please ignore this until new website is deployed.

1 Like