From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=UvRQqT8B; dkim-atps=neutral Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch [79.135.106.99]) by passt.top (Postfix) with ESMTPS id 685C25A061D for ; Sat, 08 Feb 2025 18:20:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739035202; x=1739294402; bh=OFqrWDGAabu6jS7e93CWWQ+ifjFTKSRx4OwNih7sYvM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=UvRQqT8BTWRLCXANiUmRvp/IlE5lyGwbJoUJyBend7/pAddiyxAsZxxB15v+BYEQ+ ynQ0+v1wOovBfx/GA5O9Gu3DkVPtsrJ4k+5igOGkGvk82WasPiVyTstLO6J5sNraad vfF642fROAevt25VpEl3Jreff5w6uoSrOw2JuRVfy78qvcuPmbuXDpUJexGFWFAb5h rh0aIF8F9ESyjsmpPlDLplFCbkwSiU68/TAoN/Omp4wPrrdt4ADt5CYeK5SvQg+6dP JFyKY6f/MBr7awBcy6YnCAYhPtS4xEA8TUC3LgknqoO40tEjKdjEsuFNIhQaPNt3FA mwsqWO/PsNlmQ== Date: Sat, 08 Feb 2025 17:19:59 +0000 To: Stefano Brivio From: Prafulla Giri Subject: Re: Apparmor (and other) Issues Message-ID: In-Reply-To: <20250207101631.0875e141@elisabeth> References: <20250204201448.0bf3f7a3@elisabeth> <20250204233441.6cda8c64@elisabeth> <20250205111651.59551470@elisabeth> <20250207101631.0875e141@elisabeth> Feedback-ID: 33818994:user:proton X-Pm-Message-ID: 88f60e773053960223828be3d0e1faaea9718bdc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: R7X7O75R2KGH3HHNVGNTX3JYO2T3B52Z X-Message-ID-Hash: R7X7O75R2KGH3HHNVGNTX3JYO2T3B52Z X-MailFrom: prafulla.giri@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Andrea Bolognani , "passt-dev@passt.top" X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Friday, February 7th, 2025 at 3:01 PM, Stefano Brivio wrote: > On Fri, 07 Feb 2025 06:49:45 +0000 > Prafulla Giri prafulla.giri@protonmail.com wrote: >=20 > > On Wednesday, February 5th, 2025 at 4:01 PM, Stefano Brivio > > sbrivio@redhat.com wrote: > >=20 > > > But the libvirt profile is not associated to the > > > process, oops. > >=20 > > Oh, so this is what is being worked upon: that Apparmor is not making > > the association >=20 >=20 > That, I'm not sure, but at least Andrea asked openSUSE and Ubuntu > people for comments. I just prepared (and merged) a workaround for the > moment. You are Cc'ed on the patch. If you want to test it, you should > add this: >=20 > # Workaround: libvirt's profile comes with a passt subprofile which inclu= des, > # in turn, , and adds libvirt-specific rules on top, = to >=20 > # allow passt (when started by libvirtd) to write socket and PID files in= the > # location requested by libvirtd itself, and to execute passt itself. > # > # However, when libvirt runs as unprivileged user, the mechanism based on > # virt-aa-helper, designed to build per-VM profiles as guests are started= , > # doesn't work. The helper needs to create and load profiles on the fly, = which > # can't be done by unprivileged users, of course. > # > # As a result, libvirtd runs unconfined if guests are started by unprivil= eged > # users, starting passt unconfined as well, which means that passt runs u= nder > # its own stand-alone profile (this one), which implies in turn that exec= ve() > # of /usr/bin/passt is not allowed, and socket and PID files can't be wri= tten. > # > # Duplicate libvirt-specific rules here as long as this is not solved in > # libvirt's profile itself. > /usr/bin/passt r, > owner @{run}/user/[0-9]/libvirt/qemu/run/passt/ rw, > owner @{run}/libvirt/qemu/passt/* rw, >=20 > to your /etc/apparmor.d/usr.bin.passt. Note that changes to AppArmor > policy files are retained as configuration, so, if you edit it, package > upgrades won't override things automatically. You will need to: >=20 I seem to have botched things up really good, or we're getting into more an= d more trouble here: 1. I have manually `make install`-ed passt (and friends). $ passt version # I don't know what's causing the non-AVX2 thing issue Can't run AVX2 build, using non-AVX2 version: Permission denied passt 2025_01_21.4f2c8e7-27-gfe8b6a7 Copyright Red Hat GNU General Public License, version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. This is my apparmor profile (for /usr/local/bin/passt): $ cat /etc/apparmor.d/usr.bin.passt # SPDX-License-Identifier: GPL-2.0-or-later # # PASST - Plug A Simple Socket Transport # for qemu/UNIX domain socket mode # # PASTA - Pack A Subtle Tap Abstraction # for network namespace/tap device mode # # contrib/apparmor/usr.bin.passt - AppArmor profile for passt(1) # # Copyright (c) 2022 Red Hat GmbH # Author: Stefano Brivio abi , include profile passt /usr/local/bin/passt{,.avx2} { include # Alternatively: include owner /tmp/**=09=09=09=09w,=09# tap_sock_unix_open(), =09=09=09=09=09=09# tap_sock_unix_init(), pcap(), =09=09=09=09=09=09# pidfile_open(), =09=09=09=09=09=09# pidfile_write(), =09=09=09=09=09=09# logfile_init() owner @{HOME}/**=09=09=09w,=09# pcap(), pidfile_open(), =09=09=09=09=09=09# pidfile_write() # Workaround: libvirt's profile comes with a passt subprofile which inclu= des, # in turn, , and adds libvirt-specific rules on top, = to # allow passt (when started by libvirtd) to write socket and PID files in= the # location requested by libvirtd itself, and to execute passt itself. # # However, when libvirt runs as unprivileged user, the mechanism based on # virt-aa-helper, designed to build per-VM profiles as guests are started= , # doesn't work. The helper needs to create and load profiles on the fly, = which # can't be done by unprivileged users, of course. # # As a result, libvirtd runs unconfined if guests are started by unprivil= eged # users, starting passt unconfined as well, which means that passt runs u= nder # its own stand-alone profile (this one), which implies in turn that exec= ve() # of /usr/bin/passt is not allowed, and socket and PID files can't be wri= tten. # # Duplicate libvirt-specific rules here as long as this is not solved in # libvirt's profile itself. /usr/local/bin/passt r, owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw, owner @{run}/libvirt/qemu/passt/* rw, } I have restarted the machine after making these changes, for good measure. Then: $ virsh start --domain vm1 # throws the following error: error: Failed to start domain 'vm1' error: internal error: Child process (passt --one-off --socket /run/user/10= 00/libvirt/qemu/run/passt/1-vm1-net0.socket --pid /run/user/1000/libvirt/qe= mu/run/passt/1-vm1-net0-passt.pid) unexpected exit status 126: libvirt: er= ror : cannot execute binary passt: Permission denied However, $ passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0= .socket --pid /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0-passt.pid # = this command on it's own works Can't run AVX2 build, using non-AVX2 version: Permission denied No interfaces with usable IPv6 routes UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/1-vm1-net= 0.socket Template interface: enp1s0 (IPv4) MAC: host: 9a:55:9a:55:9a:55 NAT to host 127.0.0.1: 192.168.100.1 DHCP: assign: 192.168.100.157 mask: 255.255.255.0 router: 192.168.100.1 DNS: 192.168.100.1 DNS search list: . You can now start qemu (>=3D 7.2, with commit 13c6be96618c): kvm ... -device virtio-net-pci,netdev=3Ds -netdev stream,id=3Ds,server= =3Doff,addr.type=3Dunix,addr.path=3D/run/user/1000/libvirt/qemu/run/passt/1= -vm1-net0.socket or qrap, for earlier qemu versions: ./qrap 5 kvm ... -net socket,fd=3D5 -net nic,model=3Dvirtio If, however, I uninstall the manually made version (with the apparmor profi= le back to pointing to /usr/bin/passt): $ passt --version passt 0.0~git20250121.4f2c8e7-1 Copyright Red Hat GNU General Public License, version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ virsh start --domain vm1=20 Domain 'vm1' started So I figure it's okay after all. I am surprised, the upstream tree does not seem to contain the recent DNS r= elated patch that I shazamed and tested just a couple of days earlier ( b4 = shazam https://archives.passt.top/passt-dev/20250203082210.2114348-1-sbrivi= o@redhat.com/ ). I have just emailed a reply at the patch's own thread, too= : https://archives.passt.top/passt-dev/pXatirFM4Zm6ZSKXYsfeyZnHlL8JlQDKRUNt= yLqbzrUOFcItX06upuk1cPYaufL1HzqHygkWvySVhawtV8zVi8Ou9qmhz_EvuQxr46UOi3Q=3D@= protonmail.com/ Please let me know if I'm still missing (or failing to report) something. I= 'd hate to unknowingly be a bottle-neck by failing to test/report something= . > apt-get -o Dpkg::Options::=3D"--force-confmiss" install --reinstall passt >=20 > > whereas SELinux is doing it's thing as it's supposed to. >=20 >=20 > Right, that's because SELinux can do this: >=20 > https://selinuxproject.org/page/MultiCategorySecurity >=20 > with AppArmor, it needs to be "emulated", somehow. >=20 > > > We're just trying to make things as > > > strict as possible, and depending on specific paths. > >=20 > > I see. I'm glad this approach of as-strict-as-possible is being taken. > >=20 > > > We'll probably need to make them a bit looser for the moment being > > > and perhaps just allow passt, no matter who starts it, to write to > > > /var/run/**. > >=20 > > I believe user-mode virtual machines only need access to > > /run/user/$USER and not /var/run. Not even /run/*, but only > > /run/user/$USER. So if that work-around is to be implemented, that > > would be the strictest version of it: each user-started passt process > > gets access to $XDG_RUNTIME_DIR of it's owner (and not outside of it). >=20 >=20 > It depends, because if you start passt as root, socket and PID go to > @{run}/libvirt/qemu/passt/, and if you don't, the location becomes > @{run}/user/[0-9]/libvirt/qemu/run/passt/*. >=20 > @{run} is an AppArmor handle for /var/run and /run, I think (aren't > they generally linked anyway?). Note that Ubuntu and openSUSE might > use slightly different paths. >=20 /var/run deems to be a symbolic link to /run which is a tmpfs mount on my D= ebian Trixie machine. > > It also seems that more and more of us use $XDG_RUNTIME_DIR in lieu > > of /tmp in our personal shell scripts, because it kinda' feels like a > > more private /tmp. >=20 >=20 > Yeah, it is. >=20 > > Also, the `passt` update fixing DNS issue hasn't yet made it to > > Debian Trixie, yet. >=20 >=20 > I didn't release the fix yet. I merged it (upstream), but actually I > was expecting you would give it a quick try. If I'm more confident > about the change, I can do things faster. >=20 I thought I'd already reported it working, but, as I mentioned earlier, the= patch from isn't available on the master branch yet: https://archives.pass= t.top/passt-dev/pXatirFM4Zm6ZSKXYsfeyZnHlL8JlQDKRUNtyLqbzrUOFcItX06upuk1cPY= aufL1HzqHygkWvySVhawtV8zVi8Ou9qmhz_EvuQxr46UOi3Q=3D@protonmail.com/ Perhaps I'm missing something. > > I should venture to Debian Sid, myself. >=20 >=20 > It's not in Debian Sid either because I didn't make a new release of > passt, yet. >=20 > It probably makes sense to make one next week (we release quite often, > especially if there's one or more fixes that might be important for > somebody, such as this one). As Debian maintainer I also update Debian > packages within a couple of hours. >=20 > Sid to testing is usually five days of difference, look: >=20 > https://tracker.debian.org/pkg/passt/news/ >=20 > -- > Stefano