Dear Maintainer,
I just tried to run virt-sysprep on a system with passt installed (as a
recommended dep of podman) and I'm getting this error:
$ virt-sysprep -v -d deb-tmp --enable customize \
--network \
--install openssh-server \
--ssh-inject root:file:"$HOME"/.ssh/id_rsa_vagrant.pub \
--run-command 'dpkg-reconfigure openssh-server' \
--mkdir /usr/lib/repart.d \
--append-line '/usr/lib/repart.d/50-root.conf:[Partition]' \
--append-line '/usr/lib/repart.d/50-root.conf:Type=root' \
--hostname deb-tmp
[…]
libguestfs: command: run: passt
libguestfs: command: run: \ --one-off
libguestfs: command: run: \ --socket /run/user/1000/libguestfsBF3BBT/passt.sock
libguestfs: command: run: \ --pid /run/user/1000/libguestfsBF3BBT/passt1.pid
libguestfs: command: run: \ --address 169.254.2.15
libguestfs: command: run: \ --netmask 16
libguestfs: command: run: \ --mac-addr 52:56:00:00:00:02
libguestfs: command: run: \ --gateway 169.254.2.2
Failed to bind UNIX domain socket: Permission denied
virt-sysprep: error: libguestfs error: passt exited with status 1
The system journal says:
kernel: audit: type=1400 audit(1730904512.692:218): apparmor="DENIED" operation="mknod" class="file" profile="passt" name="/run/user/1000/libguestfsBF3BBT/passt.sock" pid=2722319 comm="passt.avx2" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
I had to disable the AppArmor profile for passt to make this work.
Hi,
I think we need an AppArmor policy for guestfs-tools similar to what is
currently shipped for libvirtd, say:
profile passt {
/usr/bin/passt r,
signal (receive) set=("term") peer=/usr/bin/virt-sysprep,
signal (receive) set=("term") peer=virt-sysprep,
# for launch_passt(), lib/launch-direct.c
# and similar rules for /usr/bin/virt-*
owner @{run}/user/[0-9]*/libguestfs*/* rw,
owner @{run}/libguestfs*/* rw,
include if exists <abstractions/passt>
}
because passt(1) just ships an abstraction, but its AppArmor policy
isn't aware of where socket (--socket) or PID (--pid) files will be
created.
Let me know if you need more details, if I should submit a patch, and if
this should be reassigned to guestfs-tools or libguestfs. Thanks.
Hi,
I think we need an AppArmor policy for guestfs-tools similar to what is
currently shipped for libvirtd, say:
profile passt {
/usr/bin/passt r,
signal (receive) set=("term") peer=/usr/bin/virt-sysprep,
signal (receive) set=("term") peer=virt-sysprep,
# for launch_passt(), lib/launch-direct.c
# and similar rules for /usr/bin/virt-*
owner @{run}/user/[0-9]*/libguestfs*/* rw,
owner @{run}/libguestfs*/* rw,
include if exists <abstractions/passt>
}
because passt(1) just ships an abstraction, but its AppArmor policy
isn't aware of where socket (--socket) or PID (--pid) files will be
created.
Let me know if you need more details, if I should submit a patch, and if
this should be reassigned to guestfs-tools or libguestfs. Thanks.
Thanks for forwarding this. The use of passt is a change of behaviour that affects all guestfs tools, guestfish, and virt-v2v. It was caused by this change: https://github.com/libguestfs/libguestfs/commit/02bbc9daa742a3f9ed128e8a74546980f2b3670a (and similar commits around that one), starting in libguestfs 1.52: https://libguestfs.org/guestfs-release-notes-1.52.1.html#build-changes Do you know where the apparmor profile is shipped right now? Could it be in libvirt (src/security/apparmor)? We don't ship any SELinux or apparmor profiles upstream in libguestfs or the tools, so assigning the bug upstream to us won't result in any useful outcome. Rich.
Yes, but that's the one for libvirt components themselves, and used on Debian without changes from upstream. I don't think that that AppArmor profile should cover libguestfs as well, correct? Note that, as far as I know, this issue only happens with libguestfs using "direct" mode (even though it's not explicitly set anywhere, so I'm not sure I got this right). Right... I noticed as I wanted to submit an upstream patch for libguestfs to fix this and I realised that there are no AppArmor profiles there. By "reassigning to guestfs-tools or libguestfs" I actually meant the downstream packages.
I'm not sure. Probably the answer is whatever the thing is that now allows libguestfs to launch qemu directly, should also allow libguestfs to launch passt directly. Direct mode (run qemu directly) is the upstream default, and also used by Debian. But it's not what we use in Fedora. In Fedora we use the libvirt mode (run qemu via libvirt). This affects passt because in libvirt mode (on Fedora) the session libvirtd will run passt. So you should expect that Debian & Fedora behave differently, as well as the AppArmour vs SELinux difference. .. in Debian. A similar bug was assigned to selinux-policy in RHEL: https://issues.redhat.com/browse/RHEL-65502 Rich.
On Tue, 12 Nov 2024 13:52:43 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: The thing that allows libguestfs to launch QEMU directly is the lack of an AppArmor profile for QEMU, which therefore runs as non-profiled (unrestricted). Given that passt ships its own abstraction, we need to add a profile for libguestfs, including the abstraction for passt, which tells AppArmor where passt can write its socket and PID file, if started by libguestfs. There's a similar mechanism in SELinux, based on interfaces. Breaking down the passt "subprofile" example I shared earlier on this ticket: This should be part of the new profile for, say, virt-sysprep. The subprofile allows passt to: - read /usr/bin/passt - receive SIGTERM from virt-sysprep - read and write files (socket and PID file) there - plus everything that the passt abstraction allows Ah, thanks for solving the mystery. Right. That's not a public link, but anyway, yes, on Fedora and RHEL things work differently because libvirt doesn't ship its own profile there, so the rules come from the "core" SELinux policy. On Debian, there's no such thing, and libvirt ships its own bit. Here, I think we finally have to add AppArmor profiles for guestfs-tools (or libguestfs). I can help with that if desired. I would suggest to start with something very loose where the tools can write and read pretty much everywhere. If it's too complicated, as a short term solution, we could ship those as part of the libvirt package or as part of passt.
Annoying. I should have made it public now. Rich.
On Tue, 12 Nov 2024 15:10:38 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: In any case, that has nothing to do with this issue: there, we had accesses to passwd(5) not covered by the SELinux policy, and it's fixed by: https://passt.top/passt/commit/?id=5e2446667729d01ef8208d0e7e866cee09c8a3fb in the AppArmor policy, we are already including the appropriate abstraction (<abstractions/nameservice>) for that. Back to the topic at hand: I started playing with an AppArmor profile for guestfs-tools. For example, for virt-sysprep, this works at least for basic operation:
So, I went ahead and submitted a proposal for a very loose initial AppArmor profile for guestfs-tools: https://salsa.debian.org/libvirt-team/guestfs-tools/-/merge_requests/1 I checked functionality of several tools, with and without passt, as root and as regular user, etc. Outside of the passt subprofile, rules should be loose enough as to be quite unlikely to introduce any issue.
We believe that the bug you reported is fixed in the latest version of guestfs-tools, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1086844@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hilko Bengen <bengen@debian.org> (supplier of updated guestfs-tools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Wed, 27 Nov 2024 21:31:37 +0100 Source: guestfs-tools Architecture: source Version: 1.52.2-2 Distribution: unstable Urgency: medium Maintainer: Hilko Bengen <bengen@debian.org> Changed-By: Hilko Bengen <bengen@debian.org> Closes: 1086844 Changes: guestfs-tools (1.52.2-2) unstable; urgency=medium . [ Stefano Brivio ] * Introduce AppArmor profile (Closes: #1086844) . [ Hilko Bengen ] * Add build-dependency for AppArmor profile Checksums-Sha1: bedc3c1971bb6edbcb96871b72227c07e4a8fe0c 3327 guestfs-tools_1.52.2-2.dsc 5d753411f732a728053ce70becb2167a70fd5420 4760 guestfs-tools_1.52.2-2.debian.tar.xz e2cf3d7cb480041d7d15d2059cbab77508608fd8 15883 guestfs-tools_1.52.2-2_source.buildinfo Checksums-Sha256: 2d359780f5faec85913af9f5bff748f99a045699b674f7256f51ccc6fb179284 3327 guestfs-tools_1.52.2-2.dsc d4ea20aaf022f584f4d8ac551f946cffeeafa905ca4e8ec37464d5a4592da801 4760 guestfs-tools_1.52.2-2.debian.tar.xz 3907be597942c2a65a7569167ea4319ffee4c062dfddada62edca944351a6a7c 15883 guestfs-tools_1.52.2-2_source.buildinfo Files: d893d9d453f12113cd3b425502e2b66c 3327 utils optional guestfs-tools_1.52.2-2.dsc 32b5993de7ffc4fc89b6685d77f786e0 4760 utils optional guestfs-tools_1.52.2-2.debian.tar.xz d3527cc93465efc8e6138e00277ac900 15883 utils optional guestfs-tools_1.52.2-2_source.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEErnMQVUQqHZbPTUx4dbcQY1whOn4FAmdHkLIACgkQdbcQY1wh On7dRg//dWc7cdGqf25WmUcSTtyl13yBt4xNzn9Mg29obq9e8dcXyWHF8Rjt7IUc 6Lmi4C/snikHrphpvWClr01kty+R21Sf8U4lMNbfq3orMK0g6t1PyLDx0SrEmmy3 e69ufK406tiJmkJLnelp4eV5m/RLnCjHfvqAntwjT2qOkIpV56e5IvL9TV2nsXpd tFWxyYCGlj/uDqCQmqfLqnOxwQyPRHlW81yViw1HXHSZDZx/isE9R/emCLx3/nPM peMF+s1e1cNa2T5UQTSbSy2g4emRPNe3ihT9uPeobEKo5eYQ/ZZg+e3UunRoLLqi EpwKTQ6XRNgH26hbvqX4oDWYGB4Hfo5EK7cT5UXKAMKqg0xuN1MwRkpaUitA5RvB bIhML8H8dG451qXX/LF9CcIH9Knjy0dpAhS5h9qQQERqZ7D+ZvfFyl4T4uGvrS0t r/WQ5q1h4lRjon2w3BOYC6WH8H6XfLJ1Cy2NmJn0RMM6l7P7fsem1HUClOt6tSej PDq5vqIH8a04GMA+dzVrLOtPcWwyuCtj/hyjFgtI7m3z4PpSB5pPrr88tEEwsprL uU5nxcadWeLAu2sZALhy/CBdnz96CuBWa32DLxnfYtMBcbQo22xEa6KtiBFvyqK9 McqvnmNbkUsq2bXGcoTK59vs7A02JkiH+ViFyKHLYC9y9JRsrW4= =5WED -----END PGP SIGNATURE-----
* Stefano Brivio: Stefano, I have added your patch to the package and uploaded a new version. Thanks. Rich, do you think the AppArmor policy should be part of the upstream source distribution? Cheers, -Hilko
I don't really have an opinion on it. For SELinux policies, they have traditionally been shipped monolithically downstream. But in a relatively recent change some are now shipped upstream, eg the one for passt is here: https://passt.top/passt/tree/contrib/selinux I think my only concern is how portable AppArmor policies are between distros that use them. (I think for SELinux, they're not very portable between eg. Fedora & SUSE). Rich.
In practice the libvirt AppArmor policy only cares about Debian/Ubuntu, and once we ship SELinux it will only care about Fedora/RHEL. I figure if other distros need changes, at least by shipping something we give them a guide for what we consider a sane "baseline" policy that they can patch on top of. Overall I think it is right for upstreams to ship both apparmor and selinux policies themselves. The idea of a single centralized policy package is not scalable, and is bad at adapting in a timely manner to changes coming from new app releases. It is especially bad at dropping obsolete rules since the centralized policy may be used with arbitrarily old releases. With regards, Daniel
On Thu, 28 Nov 2024 10:46:35 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: The advantage, I think, is that you can keep tighter and smaller policies this way, because if you need a specific permission you can add it in a specific version of the related package (passt-selinux on Fedora), and also drop it when it's not needed anymore. But surely it's added effort. By the way, if you're wondering, guestfs-tools didn't hit this issue on openSUSE simply because XDG_RUNTIME_DIR is not defined there, so libguestfs asks passt to write socket and PID files under /tmp, say: libguestfs: command: run: \ --socket /tmp/libguestfsyoFS2l/passt.sock libguestfs: command: run: \ --pid /tmp/libguestfsyoFS2l/passt1.pid and, given that there's no profile for guestfs-tools, passt runs under its own convenience stand-alone profile, which allows read-write access to /tmp/**. But this happens pretty much by chance, that's now how it was supposed to work. For example, when libvirt starts passt (still on openSUSE), the matching profile is applied, because libvirt ships its AppArmor policy upstream, and it works as intended on Debian and openSUSE (I didn't check Ubuntu). AppArmor policy changes for libvirt are also routinely reviewed by SUSE people: https://gitlab.com/libvirt/libvirt/-/commit/81493d8eb6ec5d3f063b0b5770df33ed656d6766 ...and except for some rare differences (such as the one I just mentioned regarding XDG_RUNTIME_DIR) things are quite compatible. The "guestfs-tools" profile I just wrote for Debian also works, unmodified, on a current openSUSE Tumbleweed.
Sadly too many captcha &c for me to sign up for an account there :-( Hope it goes well. Rich.
On Thu, 2 Jan 2025 09:52:38 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: Sure, Hilko merged it a while ago and the issue was fixed in guestfs-tools 1.52.2-2, late November 2024. I still need to take care of some follow-up comments but it's just clean-ups, nothing affecting functionality.