Bug#1061678: passt: apparmor denies access to /run/user/$UID/libvirt/qemu/run/passt/
reassign 1061678 libvirt
On Mon, 29 Jan 2024 14:03:38 +0100
Stefano Brivio wrote:
> [...]
>
> Then, in libvirtd's policy, specific rules cover the paths for socket
> and PID files as needed by libvirtd itself. To solve this, we need a
> change in libvirtd's policy. You can try adding:
>
> owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
>
> in the 'profile passt' block of /etc/apparmor.d/usr.sbin.libvirtd, and
> it should work.
...which is now libvirt upstream commit f95675fdbb42 ("apparmor: Add
user session path for PID and socket files used by passt").
--
Stefano
Bug#1061678: passt: apparmor denies access to /run/user/$UID/libvirt/qemu/run/passt/
Andi, thanks for reporting this.
Andrea,
On Sun, 28 Jan 2024 17:16:38 +0100
"Andreas B. Mundt" wrote:
> Package: passt
> Version: 0.0~git20231230.f091893-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: a...@debian.org
>
> Hi,
>
> I tried to run a VM using libvirt with user mode networking and
> 'passt':
> …
>
>
>
>
>
> …
> Starting the machine fails and the log shows:
>kernel: audit: type=1400 audit(1706457189.881:713): apparmor="DENIED"
> operation="mknod" …
>libvirtd[752859]: internal error: Child process (passt --one-off
>--socket
> /run/user/1000/libvirt/qemu/run/passt/47-debiantesting-6-net0.socket
>--pid
> /run/user/1000/libvirt/qemu/run/passt/47-debiantesting-6-net0-passt.pid
>[…]
>PID file open: Permission denied
I was trying to find out why I don't hit this on my system, and there I
have, in /etc/apparmor.d/usr.sbin.libvirtd:
owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
but at the end of the discussion we had back then, you submitted this
as part of the libvirt patch (then merged as commit 7a39b04d683f
"apparmor: Enable passt support"):
owner /{,var/}run/libvirt/qemu/passt/* rw,
which, I guess, only works when root uses virsh to start the guests.
I suppose we need both rules to cover both root and non-root cases?
> I guess the path to socket and pid file is not allowed from
> '/etc/apparmor.d/usr.bin.passt'. After 'aa-teardown' it works as
> expected.
>
> To Reproduce the issu:
> passt --debug --one-off \
> --socket /run/user/1000/libvirt/qemu/run/passt/38-debiantesting-net0.socket
> \
> --pid /run/user/1000/libvirt/qemu/run/passt/38-debiantesting-net0-passt.pid
Andi, this is actually expected: what passt(1) itself needs as AppArmor
is provided by its abstraction, /etc/apparmor.d/abstractions/passt.
This is sourced by /etc/apparmor.d/usr.bin.passt as an example of stand-alone
usage, as well as from /etc/apparmor.d/usr.sbin.libvirtd.
Then, in libvirtd's policy, specific rules cover the paths for socket
and PID files as needed by libvirtd itself. To solve this, we need a
change in libvirtd's policy. You can try adding:
owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
in the 'profile passt' block of /etc/apparmor.d/usr.sbin.libvirtd, and
it should work.
> Thanks and best regards,
>
> Andi
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers stable-security
> APT policy: (500, 'stable-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages passt depends on:
> ii libc6 2.37-13
>
> passt recommends no packages.
>
> Versions of packages passt suggests:
> ii apparmor 3.0.12-1+b2
>
> -- no debconf information
--
Stefano
Bug#1032968: unblock: passt/0.0~git20230309.7c7625d-1
On Thu, 16 Mar 2023 16:22:33 +0100 Paul Gevers wrote: > Hi Stefano, > > On 14-03-2023 22:44, Stefano Brivio wrote: > > - full slirp4netns(1) compatibility not granted > > I've never heard of this before, what does that mean for the user? pasta(1) is supposed to provide a drop-in replacement for slirp4netns(1): you create a network namespace, as a regular user, and it can give that namespace network connectivity without creating any interface outside it. The main distinction is that it's written with performance, IPv6, and security in mind, but functionally it's supposed to be a superset of it. It has other functionalities (such as full IPv6 support), so it's not useless otherwise, but it's probably unexpected for users (and I see it as a source of potential bugs) that they can't set an outbound address as they could do it on slirp4netns. > > [ Tests ] > > I ran the upstream test suite against the packaged version on a > > Debian testing (Bookworm) x86_64 system. > > If you can do this manually, you can probably also do it automatically. > If you turn this into an autopkgtest [1] your package could migrate > without our intervention (providing that it passes on all architectures > where the binary builds and that it tests a substantial part of the > as-installed binaries). Salsa seems to be inaccessible at the moment (and I can't fetch that link from archive.org), but yes, I started reading about it just after I realised the migration was blocked, so I know a bit already. The current problem with the upstream test suite is that it takes a long time to complete, and has a lot of dependencies, including things that are not packaged in Debian (e.g. https://github.com/google/neper/). But most of those dependencies (and time) are only needed for performance tests, and we're working to refactor the test framework to make it reasonably modular. It's not exactly trivial as we spawn virtual machines and there are context dependencies between test cases, so it will probably take a while. Just to give an idea, screen capture of latest run: https://passt.top/#continuous-integration Once that is done, it should be trivial (from what I remember of the document you linked) to create autopkgtests for it. We also have optional tests (which I run from time to time) to check build and basic functionality on several distributions, including a few flavours of Debian: https://passt.top/passt/tree/test/distro/debian but that makes little sense now that it's packaged (and that we'll be able to have distribution tests... in distributions, eventually). -- Stefano
Bug#1022886: ITP: passt -- Unprivileged user-mode network connectivity for virtual machines and containers
Package: wnpp Severity: wishlist Owner: Stefano Brivio X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: passt Version : 0.0~git20221026.f212044 Upstream Author : Stefano Brivio * URL : https://passt.top/ * License : AGPL-3.0-or-later AND BSD-3-Clause Programming Lang: C Description : Unprivileged user-mode network connectivity for virtual machines and containers passt implements a translation layer between a Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't require any capabilities or privileges, and it can be used as a simple replacement for Slirp. pasta (same binary as passt, different command) offers equivalent functionality, for network namespaces: traffic is forwarded using a tap interface inside the namespace, without the need to create further interfaces on the host, hence not requiring any capabilities or privileges. This might become a dependency for other packages such as libvirt and podman. Having it packaged in Debian would actually favour adoption of this solution over libslirp/slirp4netns, which provide a similar functionality but limited in many aspects, with generally poorer performance and with a codebase that originates from a very different purpose, that showed a number of security issues in its long history. I filed a RFP in the past, at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010498 I now plan to maintain this package as sponsored maintainer, and I already contacted a sponsor.
Bug#1010498: RFP: passt -- Unprivileged user-mode network connectivity for virtual machines and containers
Sorry, wrong link, it's actually: https://passt.top/passt/tree/contrib/debian
Bug#1010498: RFP: passt -- Unprivileged user-mode network connectivity for virtual machines and containers
Package: wnpp Severity: wishlist * Package name: passt Version : 0+git-32210fb64f7d Upstream Author : Stefano Brivio * URL : https://passt.top/ * License : AGPL-3.0-or-later AND BSD-3-Clause Programming Lang: C Description : user-mode networking daemons for virtual machines and containers passt implements a translation layer between a Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't require any capabilities or privileges, and it can be used as a simple replacement for Slirp. pasta (same binary as passt, different command) offers equivalent functionality, for network namespaces: traffic is forwarded using a tap interface inside the namespace, without the need to create further interfaces on the host, hence not requiring any capabilities or privileges. This might become a dependency for other packages such as libvirt and podman. Having it packaged in Debian would actually favour adoption of this solution over libslirp/slirp4netns, which provide a similar functionality but limited in many aspects, with generally poorer performance and with a codebase that originates from a very different purpose, that showed a number of security issues in its long history. I don't plan to maintain this package -- this is actually an RFP. An example of Debian packaging files is available upstream at: https://passt.top/contrib/debian including dh_apparmor rules for the example policy from: https://passt.top/passt/tree/contrib/apparmor
