AppArmor profile required to start up on Ubuntu 24.04

Description

An AppArmor profile is required for chromium (and therefore electron) based applications to start up on Ubuntu 24.04 in its default configuration.

Current behavior

Without the presence of an apparmor profile, jitsi-meet crashes on startup with the following output:

$ jitsi-meet 
LaunchProcess: failed to execvp:
/opt/Jitsi
[1050993:0605/154157.982275:FATAL:zygote_host_impl_linux.cc(201)] Check failed: . : Invalid argument (22)
Trace/breakpoint trap (core dumped)

Unsurprisingly, the core dump doesn't give much useful information at all:

# coredumpctl info 1039661
           PID: 1039661 (jitsi-meet)
           UID: 1000 (koniiiik)
           GID: 1000 (koniiiik)
        Signal: 5 (TRAP)
     Timestamp: Wed 2024-06-05 15:05:22 CEST (43min ago)
  Command Line: $'/opt/Jitsi Meet/jitsi-meet'
    Executable: /opt/Jitsi Meet/jitsi-meet
 Control Group: /user.slice/user-1000.slice/user@1000.service/tmux-spawn-a8945128-a26f-4fa6-a931-4d6d4b176eca.scope
          Unit: user@1000.service
     User Unit: tmux-spawn-a8945128-a26f-4fa6-a931-4d6d4b176eca.scope
         Slice: user-1000.slice
     Owner UID: 1000 (koniiiik)
       Boot ID: d7d6bc23fc4444ed867a6ac6b95c9f31
    Machine ID: f119a149e96043a0a8d0bb71b3e08050
      Hostname: parahippus
       Storage: /var/lib/systemd/coredump/core.jitsi-meet.1000.d7d6bc23fc4444ed867a6ac6b95c9f31.1039661.1717592722000000.zst (present)
  Size on Disk: 1.6M
       Message: Process 1039661 (jitsi-meet) of user 1000 dumped core.

                Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.amd64
                Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.amd64
                Stack trace of thread 1039661:
                #0  0x000056bf74d5c04a n/a (jitsi-meet + 0x5ce004a)
                #1  0x000056bf74d5b832 n/a (jitsi-meet + 0x5cdf832)
                #2  0x000056bf74d5b2dd n/a (jitsi-meet + 0x5cdf2dd)
                #3  0x000056bf74d5c2f0 n/a (jitsi-meet + 0x5ce02f0)
                #4  0x000056bf74d453d3 n/a (jitsi-meet + 0x5cc93d3)
                #5  0x000056bf7442f4e1 n/a (jitsi-meet + 0x53b34e1)
                #6  0x000056bf717ec749 n/a (jitsi-meet + 0x2770749)
                #7  0x000056bf738b2d96 n/a (jitsi-meet + 0x4836d96)
                #8  0x000056bf7284f83b n/a (jitsi-meet + 0x37d383b)
                #9  0x000056bf717eb79d n/a (jitsi-meet + 0x276f79d)
                #10 0x000056bf717e94d3 n/a (jitsi-meet + 0x276d4d3)
                #11 0x000056bf717e9980 n/a (jitsi-meet + 0x276d980)
                #12 0x000056bf714cf928 n/a (jitsi-meet + 0x2453928)
                #13 0x00007c049562a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
                #14 0x00007c049562a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
                #15 0x000056bf710c402a _start (jitsi-meet + 0x204802a)

                Stack trace of thread 1039662:
                #0  0x00007c049571b4cd __GI___poll (libc.so.6 + 0x11b4cd)
                #1  0x000056bf7442e0c0 n/a (jitsi-meet + 0x53b20c0)
                #2  0x000056bf74dfb505 n/a (jitsi-meet + 0x5d7f505)
                #3  0x00007c049569ca94 start_thread (libc.so.6 + 0x9ca94)
                #4  0x00007c0495729c3c __clone3 (libc.so.6 + 0x129c3c)
                ELF object binary architecture: AMD x86-64

The syslog contains a hint about this being related to apparmor:

Jun 05 15:05:22 parahippus kernel: audit: type=1400 audit(1717592722.495:328): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=1039661 comm="jitsi-meet" requested="userns_create" target="unprivileged_userns"
Jun 05 15:05:22 parahippus kernel: audit: type=1400 audit(1717592722.496:329): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=1039663 comm="jitsi-meet" capability=21  capname="sys_admin"
Jun 05 15:05:22 parahippus kernel: traps: jitsi-meet[1039661] trap int3 ip:56bf74d5c04a sp:7fffd038f590 error:0 in jitsi-meet[56bf710c4000+837d000]
Jun 05 15:05:22 parahippus systemd[1]: Started systemd-coredump@5-1039666-0.service - Process Core Dump (PID 1039666/UID 0).
Jun 05 15:05:22 parahippus systemd[1]: systemd-coredump@5-1039666-0.service: Deactivated successfully.
Jun 05 15:05:22 parahippus systemd[1]: systemd-coredump@5-1039666-0.service: Triggering OnSuccess= dependencies.
Jun 05 15:05:22 parahippus systemd[1]: Starting apport-coredump-hook@5-1039666-0.service...
Jun 05 15:05:25 parahippus systemd[1]: apport-coredump-hook@5-1039666-0.service: Deactivated successfully.
Jun 05 15:05:25 parahippus systemd[1]: Finished apport-coredump-hook@5-1039666-0.service.
Jun 05 15:05:25 parahippus systemd[1]: apport-coredump-hook@5-1039666-0.service: Consumed 2.117s CPU time.

For some reason, the DENIED message only shows up the first time on a given boot, but otherwise, the behavior is the same.

Expected Behavior

It should just start up.

Possible Solution

Adding a standard chromium boilerplate apparmor profile to /etc/apparmor.d/jitsi-meet, such as the following one, and loading it into the kernel (for example with systemctl reload apparmor) makes jitsi-meet start up fine:

abi <abi/4.0>,
include <tunables/global>

profile jitsi-meet /opt/Jitsi\ Meet/jitsi-meet flags=(unconfined) {
  userns,
  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/jitsi-meet>
}

Steps to reproduce

Install the 2024.5.0 version of jitsi-meet-amd64.deb on Ubuntu 24.04 with its default AppArmor configuration.

jitsi / jitsi-meet-electron