Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 4 Feb 2025 09:50:40 +0000
Andrea Bolognani <abologna@redhat.com> wrote:

> On Tue, Feb 04, 2025 at 09:50:00AM +0100, Stefano Brivio wrote:
> > On Tue, 04 Feb 2025 08:21:53 +0000 Prafulla Giri <prafulla.giri@protonmail.com> wrote:  
> > > type=SERVICE_START msg=audit(1738501309.082:134): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg='unit=polkit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
> > > type=AVC msg=audit(1738501309.118:135): apparmor="DENIED" operation="file_mmap" class="file" profile="passt" name="/usr/bin/passt" pid=2030 comm="passt" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0FSUID="larryboy" OUID="root"
> > > type=SYSCALL msg=audit(1738501309.118:135): arch=c000003e syscall=59 success=no exit=-13 a0=7faf24035fc0 a1=7faf24035210 a2=7ffc063280d0 a3=0 items=0 ppid=1964 pid=2030 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="passt" exe="/usr/bin/passt" subj=passt key=(null)ARCH=x86_64 SYSCALL=execve AUID="larryboy" UID="larryboy" GID="larryboy" EUID="larryboy" SUID="larryboy" FSUID="larryboy" EGID="larryboy" SGID="larryboy" FSGID="larryboy"
> > > type=PROCTITLE msg=audit(1738501309.118:135): proctitle="(null)"
> > > type=ANOM_ABEND msg=audit(1738501309.118:136): auid=1000 uid=1000 gid=1000 ses=1 subj=passt pid=2030 comm="passt" exe="/usr/bin/passt" sig=11 res=1AUID="larryboy" UID="larryboy" GID="larryboy"  
> >
> > So, it looks like passt is running as its own profile. This shouldn't
> > happen because the libvirt profile has an own subprofile and we should
> > see that in "profile" on the type=AVC line but... I just reproduced
> > this! Clean Debian sid install, fresh install of libvirtd:
> >
> > error: internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-alpine-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-alpine-net0-passt.pid --tcp-ports 40922:22) unexpected fatal signal 11
> >
> > I'll keep you posted.  
> 
> I've skimmed the conversation trying to understand whether there's
> anything that I need do from the libvirt side, but AFAICT no explicit
> action has been called for so far.

Not yet, because I was hoping to figure out what's going on, but I'm
actually (almost?) stuck now. I don't think this is the same as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094583 by the way,
because:

$ find /etc/apparmor.d/ -ls | grep -i virt
   148926      4 drwxr-xr-x   2 root     root         4096 Feb  4 08:44 /etc/apparmor.d/libvirt
   148927      4 -rw-r--r--   1 root     root          192 Jan 15 08:06 /etc/apparmor.d/libvirt/TEMPLATE.qemu
   149882      4 -rw-r--r--   1 root     root          342 Jan 15 08:06 /etc/apparmor.d/libvirt/TEMPLATE.lxc
     6098      8 -rw-r--r--   1 root     root         4780 Jan 30 22:47 /etc/apparmor.d/usr.sbin.libvirtd
    20741      0 -rw-r--r--   1 root     root            0 Feb  4 08:44 /etc/apparmor.d/local/usr.sbin.libvirtd
    20572      0 -rw-r--r--   1 root     root            0 Feb  4 08:44 /etc/apparmor.d/local/usr.lib.libvirt.virt-aa-helper
     6826     12 -rw-r--r--   1 root     root         9258 Jan 30 22:47 /etc/apparmor.d/abstractions/libvirt-qemu
    20662      8 -rw-r--r--   1 root     root         4610 Jan 30 22:47 /etc/apparmor.d/abstractions/libvirt-lxc
     6099      4 -rw-r--r--   1 root     root         1898 Jan 30 22:47 /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
$ find /etc/libvirt/    -ls | grep -i conf
find: '/etc/libvirt/secrets': Permission denied
   268888     20 -rw-r--r--   1 root     root        17826 Jan 30 22:47 /etc/libvirt/libvirtd.conf
   269240      4 -rw-r--r--   1 root     root         2169 Jan 30 22:47 /etc/libvirt/libxl-lockd.conf
   324760      4 -rw-r--r--   1 root     root          547 Nov  1 09:13 /etc/libvirt/libvirt.conf
   269243      4 -rw-r--r--   1 root     root         3058 Jan 15 08:06 /etc/libvirt/virtlockd.conf
   263460      4 -rw-r--r--   1 root     root         2465 Jan 30 22:47 /etc/libvirt/qemu-sanlock.conf
   263459      4 -rw-r--r--   1 root     root         2169 Jan 30 22:47 /etc/libvirt/qemu-lockd.conf
   269238      4 -rw-r--r--   1 root     root         1175 Jan 15 08:06 /etc/libvirt/lxc.conf
   324759      4 -rw-r--r--   1 root     root          450 Nov  1 09:13 /etc/libvirt/libvirt-admin.conf
   269241      4 -rw-r--r--   1 root     root         2465 Jan 30 22:47 /etc/libvirt/libxl-sanlock.conf
   269242      4 -rw-r--r--   1 root     root         2268 Jan 15 08:06 /etc/libvirt/libxl.conf
   263461     40 -rw-------   1 root     root        39106 Jan 30 22:47 /etc/libvirt/qemu.conf
   262245      4 -rw-r--r--   1 root     root         4095 Jan 15 08:06 /etc/libvirt/virtlogd.conf
   268889      4 -rw-r--r--   1 root     root         1041 Jan 30 22:47 /etc/libvirt/network.conf

> It looks like you're making good progress in figuring out what's
> going on. Being able to reproduce the issue yourself is certainly
> going to help. I'm happy to leave all the debugging to you, since as
> you know I'm not very good at the AppArmor stuff and I'm really,
> really bad at the networking stuff ;)

...no, wait, I'm still failing to understand the bigger picture of what
happens AppArmor-wise when I do 'virsh start something'. :)

This is really pretty simple: fresh Debian sid image, all packages
updated to today. Then:

  virt-install -d --name alpine --memory 1024 --noreboot --osinfo alpinelinux3.20 --network backend.type=passt,portForward0.proto=tcp,portForward0.range0.start=40922,portForward0.range0.to=22 --import --disk nocloud_alpine-3.21.2-x86_64-bios-tiny-r0.qcow2

this works. But:

  $ virsh start alpine
  error: Failed to start domain 'alpine'
  error: internal error: Child process (passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-alpine-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-alpine-net0-passt.pid --tcp-ports 40922:2) unexpected fatal signal 11

execve() of passt is denied by AppArmor. Starting passt on its own
(passt -f) works, instead.

At this point, which libvirtd (?) process should associate with which
libvirtd profile? Once that's clear to me, I can probably debug further.

I can also give you access to the machine if needed.

> Once a clearer picture emerges, if it turns out that changes are
> needed in either libvirt or its Debian packaging, I can definitely
> look into making that happen.

I'm fairly sure it's libvirt, because I didn't change anything
substantial in passt, and it's anyway the AppArmor profile for libvirtd
that seems to be... missing? And yet it's there.

-- 
Stefano