I am not very familiar with how to set that up on Ubuntu and I think it's worth reaching out to an Ubuntu-specific forum if the changes in Ubuntu are the cause. Are you running Chrome for Testing or Chromium? Could you please provide a Dockerfile that demonstrates the issue since I do not have an Ubuntu available?

@lewistg I'm pretty sure you need to either install the browser to the path whitelisted in /etc/apparmor.d/chrome, or create a new AppArmor profile with the actual install path. See also this article about the same issue regarding Firefox:
https://support.mozilla.org/en-US/kb/install-firefox-linux#w_security-features-warning (the formatting of the file quoted there is broken; refer to the format of the files on your machine and described in the man page)

This is how /etc/apparmor.d/chrome looks on my Ubuntu 24.04 installation:

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

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

profile chrome /opt/google/chrome/chrome flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/chrome>
}

Note that the path also allows globbing (see the linked man page).

@johannespfrang Thank you for pointing me in the right direction. That was helpful information, and I've got something working now.

Here is a little extra context: My real use case involves running Chrome/puppeteer in the context of the bazel build tool. Bazel has its own sandboxing mechanism, so when the puppeteer test gets run it will be trying to launch a Chrome binary copied to a semi-dynamic location within bazel's sandbox directory structure. I might be able to handle this with the some careful globbing, but so far I've had some luck using the app-exec command with a simple wrapper script like this one:

#!/bin/bash

# Run chrome from dynamic location using the default "chrome" profile from `/etc/apparmor.d/chrome`
aa-exec -p chrome -- "$DYNAMIC_PATH/chrome" "$@"

If you happen to know of any issues with this approach, please let me know.

@OrKoN Thanks for the quick response. I did attempt to set up a Dockerfile in case you wanted to look further. I wasn't successful, though. I might just not know enough, but I gather AppArmor and these new security features are implemented at layers below containers.

@OrKoN I started getting this in puppeteer-sharp. Do you know why we might not getting this in puppeteer builds? We both are using ubuntu-latest

@OrKoN I started getting this in puppeteer-sharp. Do you know why we might not getting this in puppeteer builds? We both are using ubuntu-latest

no idea, unfortuantely

ubuntu-latest was pointing to 22.04 but as of today (10/15/2024) it is pointing to 24.04. I am running puppeteer in a GitHub Action and was able to see the version change in the logs.

I downgraded my action to run against 22.04 (ubuntu-latest -> ubuntu-22.04). That seems to have 'fixed' the error for now or at least buys some time for me to investigate and decide how to work with the changes in ubuntu.

It seems that puppeteer CI is still on 22.04.5.

Opened a PR to test with 24.04 #13196

It fails as well. The error message seems to include instructions for Ubuntu:

[2423:2423:1016/062159.567901:FATAL:zygote_host_impl_linux.cc(128)] No usable sandbox! If you are running on Ubuntu 23.10+ or another Linux distro that has disabled unprivileged user namespaces with AppArmor, see https://chromium.googlesource.com/chromium/src/+/main/docs/security/apparmor-userns-restrictions.md. Otherwise seehttps://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the (older) SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

Filed https://crbug.com/373753919

For GitHub Actions, I can confirm (after testing on some hobby projects) that the temporary workaround to replace runs-on: ubuntu-latest with runs-on: ubuntu-22.04 works.

I solved this editing file etc/apparmor.d/unprivileged_userns

profile unprivileged_userns {
#audit deny capability, <-- commented

and adding
capability sys_admin,
capability sys_chroot,
capability sys_ptrace,
capability ipc_lock,
capability sys_resource,

was going crazy with this bug. can confirm that this also worked for me. Thanks!

For GitHub Actions, I can confirm (after testing on some hobby projects) that the temporary workaround to replace runs-on: ubuntu-latest with runs-on: ubuntu-22.04 works.