Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1061678: passt: apparmor denies access to /run/user/$UID/libvirt/qemu/run/passt/

227 views
Skip to first unread message

Andreas B. Mundt

unread,
Jan 28, 2024, 11:30:06 AM1/28/24
to
Package: passt
Version: 0.0~git20231230.f091893-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: an...@debian.org

Hi,

I tried to run a VM using libvirt with user mode networking and
'passt':

<interface type="user">
<mac address="52:54:00:cf:5c:66"/>
<model type="virtio"/>
<backend type="passt"/>
</interface>

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 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

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 Brivio

unread,
Jan 29, 2024, 8:20:04 AM1/29/24
to
Andi, thanks for reporting this.

Andrea,

On Sun, 28 Jan 2024 17:16:38 +0100
"Andreas B. Mundt" <an...@debian.org> wrote:

> Package: passt
> Version: 0.0~git20231230.f091893-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: an...@debian.org
>
> Hi,
>
> I tried to run a VM using libvirt with user mode networking and
> 'passt':
> …
> <interface type="user">
> <mac address="52:54:00:cf:5c:66"/>
> <model type="virtio"/>
> <backend type="passt"/>
> </interface>
> …
> 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

Stefano Brivio

unread,
Jan 31, 2024, 6:20:05 AM1/31/24
to
reassign 1061678 libvirt

On Mon, 29 Jan 2024 14:03:38 +0100
Stefano Brivio <sbr...@redhat.com> 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
0 new messages