A new PC with a fresh installation of Mate, Noble Numbat.
Two apps I use with no problem on Jammy Jellyfish now crash with a similar error. The apps are "Ledger Live" and "Balena Etcher". My other apps run fine on both PCs.
mike@bbbpc:~/crypto$ ledger-live-desktop-2.83.0-linux-x86_64.AppImage
[1020650:0714/123310.927233:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_ledgergViazd/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)
mike@bbbpc:~/Downloads$ balenaEtcher
[1065481:0714/130124.359896:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_balenaUe6mdQ/chrome-sandbox is owned by root and has mode 4755.
/tmp/.mount_balenaUe6mdQ/balena-etcher-electron: line 10: 1065481 Trace/breakpoint trap (core dumped) "${script_dir}"/balena-etcher-electron.bin "$@"
So, I've been doing some web searching for the error message in your post, namely the following error message that you got when trying to start the AppImage of "balenaEtcher / Balena Etcher" and "Ledger Live" in Ubuntu MATE 24.04 LTS ("Noble Numbat"):
The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now.
The apparent conclusions that I've reached are the following:
1 - Ubuntu 24.04 LTS ("Noble Numbat") - and I assume that also includes the several flavors like Ubuntu MATE, Lubuntu, Kubuntu, Xubuntu ... - introduced the following change, that is documented in the "Security Improvements" section of the Ubuntu 24.04 LTS ("Noble Numbat") Release Notes - https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890 :
" (...)
Security Improvements
Unprivileged user namespace restrictions
In combination with the apparmor package, the Ubuntu kernel now restricts the use of unprivileged user namespaces. This affects all programs on the system that are unprivileged and unconfined. A default AppArmor profile is provided that allows the use of user namespaces for unprivileged and unconfined applications but will deny the subsequent use of any capabilities within the user namespace. A common use-case for unprivileged user namespaces is applications that construct their own sandboxes or work with styles of container workloads. As such, AppArmor profiles that allow the use of unprivileged user namespaces are also provided for common applications and frameworks that come from the Ubuntu archive, as well as popular third party applications like Google Chrome, Discord and others. This is a subsequent step towards trying to mitigate the larger attack surface presented by unprivileged user namespaces (the first being the introduction of this feature in Ubuntu 23.10 where it was not enabled by default).
Whilst significant effort has been expended to try and identify all applications that may require such profiles, it is expected that there may be cases where additional profiles are required.
In this case, there are several options if you run into problems:
Confine your applications with an AppArmor profile. Because this can be potentially onerous, a new unconfined profile mode/flag has been added to AppArmor. This designates the profile to essentially act like the unconfined mode for AppArmor where an application is not restricted, and it allows additional permissions to be added, such as the userns, permission. Such profile for, e.g. Google Chrome , would look like the following, and it would be located within the /etc/apparmor.d/chrome file:
abi <abi/4.0>,
include <tunables/global>
/opt/google/chrome/chrome flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists <local/chrome>
}
Alternatively, a complete AppArmor profile for the application can be created (see the AppArmor documentation).
Launch your application in a way that doesn’t use unprivileged user namespaces, e.g. google-chrome-stable --no-sandbox. However, since this disables the use of an internal security feature within the application, this is not recommended. Instead, use the unconfined profile mode described above instead.
Disable this restriction on the entire system for one boot by executing echo 0 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns. This setting is lost on reboot. This similar to the previous behaviour, but it does not mitigate against kernel exploits that abuse the unprivileged user namespaces feature.
Disable this restriction using a persistent setting by adding a new file (/etc/sysctl.d/60-apparmor-namespace.conf) with the following contents:
kernel.apparmor_restrict_unprivileged_userns=0
Reboot. This is similar to the previous behaviour, but it does not mitigate against kernel exploits that abuse the unprivileged user namespaces feature. (...)"
Thanks for the response. I've had a quick look and tried adding an apparmor profile but that broke my snap apps so I restored a backup and will use my old PC to run those two .AppImage files for now.
I don't think Balena Etcher has the right packages and code for Ubuntu mate. You would have to install the packages yourself then install balena etcher. I dont think Balena Etcher appimages work on Ubuntu mate. so u would have to download a deb or zip file.
@ricmarques, thanks for your further investigation.
Some appimage need to run with the sandbox for security reason. The best exemple is ledger live, some critical data must have to be isolated. I need to use some appimage like this. I don't want to run it without sandbox or decrease the AppArmor profile. @mikedabike, I propose you to track and post here our testing of patch, in order to share. On my side, I just tested the apparmor 4.0.1really4.0.1-0ubuntu0.24.04.3 with ledger live and others with no success. And you?
For now, I don't migrate to 24.04 and continue to use 22.04 because this appimage sandbox bug.
That's a great suggestion, @Philippe Based on that suggestion of yours, I've just edited the title of this discussion topic to replace the word "apps" by the expression "AppImage apps". Thanks for the suggestion!
Bottom line, these are issues driven by applications "wrapped" within the confines of "snap" installations.
We are seeing, with every such report, that the "snap" ecology has not been fully regression-tested against all users/applications which were previously run using those applications in non-snap mode.
Lesson learned: don't assume snap-based migration will be smooth. Test everything, top to bottom, before dreaming of any such migration.
