feat: add passt

[NN708]

Resolves #16 .

[flathubbot]

Started test build 180823

[flathubbot]

Build 180823 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/163986/org.virt_manager.virt_manager.Extension.Qemu.flatpakref

[NN708]

During testing, I encountered the following error:

Unable to complete install: 'internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-vm-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-vm-net0-passt.pid) unexpected exit status 1: UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/1-vm-net0.socket'
Couldn't create user namespace: Operation not permitted

Traceback (most recent call last):
  File "/app/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/app/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install
    installer.start_install(guest, meter=meter)
  File "/app/share/virt-manager/virtinst/install/installer.py", line 726, in start_install
    domain = self._create_guest(
             ^^^^^^^^^^^^^^^^^^^
  File "/app/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest
    domain = self.conn.createXML(initial_xml or final_xml, 0)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/lib/python3.12/site-packages/libvirt.py", line 4545, in createXML
    raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-vm-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-vm-net0-passt.pid) unexpected exit status 1: UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/1-vm-net0.socket
Couldn't create user namespace: Operation not permitted

I'm not sure how to resolve this. Any guidance or suggestions would be appreciated.

[sbrivio-rh]

There's probably a LSM (Linux Security Module) preventing passt from detaching its user namespace, which is done for (security) sandboxing reasons, see https://passt.top/passt/tree/isolation.c.

Is this on a distribution using AppArmor? Or SELinux? For Debian, openSUSE, and Ubuntu, see https://passt.top/passt/tree/contrib/apparmor/ and, maybe also helpful: https://salsa.debian.org/sbrivio/passt/-/blob/master/debian/rules?ref_type=heads.

SELinux? Then https://passt.top/passt/tree/contrib/selinux.

[NN708]

@sbrivio-rh Thank you for the information! I tried patching passt source code to disable sandboxing, and it resolved the problem (though it does weaken security).

After further research, I found that the issue arises because Flatpak restricts applications from creating user namespaces: flatpak/flatpak#5921. Based on the discussion, it seems that the best solution for now would be to adapt passt to utilize Flatpak's flatpak-spawn sub-sandboxing. However, this would require some upstream work. Do you have any thoughts or suggestions on this?

[tulilirockz]

Yeeah its the sandboxing that breaks it, we might just need to disable the sandboxing for this, similar to what they do with chromium-based flatpaks

[NN708]

Yeeah its the sandboxing that breaks it, we might just need to disable the sandboxing for this, similar to what they do with chromium-based flatpaks

Actually, zypak still provides some level of sandboxing, so it's not the same as having no sandboxing at all.

[sbrivio-rh]

I tried patching passt source code to disable sandboxing, and it resolved the problem (though it does weaken security).

we might just need to disable the sandboxing for this

Please, let's not go that way. If it breaks, the pieces are all yours: I'm not going to support this.

By the way, is this obvious security weakness sufficiently reported to Flathub/Flatpak maintainers?

Based on the discussion, it seems that the best solution for now would be to adapt passt to utilize Flatpak's flatpak-spawn sub-sandboxing. However, this would require some upstream work. Do you have any thoughts or suggestions on this?

I didn't understand exactly how this (or zypak) would work:

• flatpak-spawn would be something passt invokes instead of sandboxing itself, correct?

• zypak uses LD_PRELOAD, but I couldn't understand at a quick look which system calls are hijacked. If it's unshare, that should work

[NN708]

Please, let's not go that way.

I agree.

By the way, is this obvious security weakness sufficiently reported to Flathub/Flatpak maintainers?

Disabling user namespaces may decrease the attack surface to the kernel, so it may not necessarily be a "security weakness". Although issue flatpak/flatpak#5921 was opened a few months ago, the discussion has only become heated this week. It might be helpful if you could ask some of your colleagues who are working on Flatpak to take a look at this.

I didn't understand exactly how this (or zypak) would work:

• flatpak-spawn would be something passt invokes instead of sandboxing itself, correct?

• zypak uses LD_PRELOAD, but I couldn't understand at a quick look which system calls are hijacked. If it's unshare, that should work

Yes, we should use the sandbox created by flatpak-spawn, and the corresponding API is org.freedesktop.portal.Flatpak.Spawn according to this comment. I'm not entirely sure, but libportal might be the library we can use. We don't need to go as far as zypak does.