49

After upgrading to 24.04, I get the The SUID sandbox helper binary was found, but is not configured correctly. message when I try to run this Electron AppImage application file. The entire error looks like this (example for Obsidian app):


> ./Obsidian-1.4.13.AppImage

[21824:0430/094557.661436: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_ObsidiOpBPaM/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

I'm unsure what it asks for; the /tmp/.mount_ObsidiOpBPaM/chrome-sandbox does not exist. The rights on /tmp are set to 4777, owner root.

How do I rerun the app?

Uri Herrera
  • 15,318
Tomas Greif
  • 695

7 Answers7

37

Probably the best way to solve the problem is to create an apparmor profile which allows the application to make use of unprivileged usernamespaces.

Create the file /etc/apparmor.d/obsidianappimage with the following content:

# 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 obsidianappimage /path/to/Obsidian-1.6.7.AppImage flags=(default_allow) {
  userns,


Site-specific additions and overrides. See local/README for details.


include if exists <local/obsidianappimage>
}

Replace /path/to/Obsidian-1.6.7.AppImage with the path to your appimage.

After saving the file run sudo systemctl reload apparmor.service to reload all apparmor profiles. If this command does not work for you, simply reboot.

Done, enjoy your appimage...

Note: Moving the appimage to a different location later or changing it's name makes it neccessary to update your apparmor profile with the correct path and reload the apparmor profiles.

This blog provides some background information.

Update:

There also exists a default profile for Obdsian provided by the Apparmor package with the following content:

# 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 obsidian /opt/Obsidian/obsidian flags=(unconfined) {
  userns,


Site-specific additions and overrides. See local/README for details.


include if exists <local/obsidian>
}

I think this profile is meant for the obsidian deb-package which is also available, but we could make use of this default profile without creating a profile as described above by simply moving the appimage to the correct location:

sudo mkdir -p /opt/Obsidian
sudo mv /path/to/Obsidian-1.6.7.AppImage /opt/Obsidian/obsidian
mook765
  • 18,644
23

Moderator's Note: There is currently an issue in AppArmor (Launchpad Bugs #2046844, #2064672 (SRU'd fix for Noble), and #2072811 (the regression bug that reverted it)) that is known to be causing problems with sandboxing of AppImages and such at this time.

There is currently no ETA on a fix for this issue at this time. Due to that, if your application you are trying to use is absolutely critical to your needs, you can use the options stated here to run the application without sandboxing. However, be advised that this can be dangerous as this lets the application directly alter things on your system.

Note that if you choose to use this answer's solutions, you accept all security risks of running any applications unsandboxed. Ask Ubuntu and the poster of this answer accept no responsibility if you damage your system in some way running applications in this manner.

Answer author's Note: The method described below seemed to be the only option at the time I wrote this answer. Due to the security issues this method should not be used anymore. Apparmor has been updated since and now we can use an apparmor profile which allows the application the use of unprivileged usernamspaces, please see my other answer.

You could run your appimage with the --no-sandbox-option:

./Obsidian-1.4.13.AppImage --no-sandbox

You could also try

 ./Obsidian-1.4.13.AppImage --disable-setuid-sandbox

Please see also https://stackoverflow.com/q/24237933

mook765
  • 18,644
14

Just downloaded the appimage again which is now version 1.6.7 but still has the same problem as described in your question.

I think I found some kind of safe solution now. I extracted the appimage and installed the extracted files in /opt/Obsidian. First we're going to extract the appimage:

~$ /home/mook/Obsidian-1.6.7.AppImage --appimage-extract

Now we move the extacted files to /opt/

~$ sudo mv /home/mook/squashfs-root /opt/Obsidian

We want to have the files owned by root:

~$ sudo chown -R root: /opt/Obsidian

We fix the permission for the sandbox file:

~$ sudo chmod 4755 /opt/Obsidian/chrome-sandbox

Some subdirectories are only accessable by root due to permissions, this prevents the application from launching, we need to fix that too:

~$ sudo find /opt/Obsidian -type d -exec chmod 755 {} \;

Now we can start the application:

~$ /opt/Obsidian/AppRun
2024-07-31 06:43:51 Loading main app package /opt/Obsidian/resources/obsidian.asar
Ignored: Error: ENOENT: no such file or directory, open '/home/mook/.config/obsidian/obsidian.json'
2024-07-31 06:43:52 Checking for update using Github
2024-07-31 06:43:52 Success.
2024-07-31 06:43:52 Latest version is 1.6.7
2024-07-31 06:43:52 App is up to date.

The application launches without complaining about permissions. I'am also able to start the application via double-click on the AppRun-file in my file manager or via menu-entry after creating a .desktop-file.

Security note:

Since we are running an executable which is owned by root and has the setuid-bit set the executable will run with root-privileges which could be considered a security issue as well. We only should do so if we trust the application. But at least the application runs sandboxed.

For me this was a temporary solution which I don't use any longer. Instead, I use an apparmor-profile now, please see my other answer.

mook765
  • 18,644
5

If you do not mind relaxing your security settings, then this fix works for me, which --no-sandbox and --disable-setuid-sandbox do not.

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Snag: you need to redo this every time you boot.

Liam Proven
  • 741
1

I get the same problem after install Kubuntu 24.04. My solution is adding nosuid mount option to /tmp by editing /etc/fstab

tmpfs                                     /tmp           tmpfs   defaults,noatime,nodiratime,nosuid,mode=1777 0 0
hrzhu
  • 776
-1

The issue arises because Ubuntu 24.04 introduced new restrictions for AppImage applications, limiting the use of sandboxes.

The solution is to disable these restrictions implemented by Ubuntu 24.04 for AppImages.

  • Use the following command to deactivate the restrictions:

    sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

  • To reactivate the restrictions, use:

    sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

eaitfakir
  • 519
  • 4
  • 4
-1

It is not recommended to use --disable-sandbox as it reduces security.
Instead, you should extract the AppImage and correctly configure chrome-sandbox permissions. Steps to Fix the Issue

  1. Make the AppImage executable and extract it
  2. Move the extracted contents to /opt/obsidian
  3. Fix the permissions for chrome-sandbox
chmod +x Obsidian-1.4.13.AppImage
./Obsidian-1.4.13.AppImage --appimage-extract
sudo mv squashfs-root /opt/obsidian
sudo chown root /opt/obsidian/chrome-sandbox
sudo chmod 4755 /opt/obsidian/chrome-sandbox

✅ Now, Obsidian should run without sandboxing errors.

afzalex
  • 161
  • 1
  • 11