50

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,328
Tomas Greif
  • 705

7 Answers7

38

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,764
  • 1
    Any reasons you used unconfined instead of default_allow as per the blog post you linked? – Kamal Oct 25 '24 at 03:17
  • @Kamal Thanks for the hint with the typo, remind, you can always edit to correct typos. I used unconfined because I copied the file from /etc/apparmor.d/flatpak, edited the copy to test if it works. I found the blog later on and added the link for completeness. I didn't recognize this difference. I'll test and edit accordingly. – mook765 Oct 25 '24 at 06:19
  • 1
    thanks! FYI I tested default_allow with Logseq and it worked. – Kamal Oct 26 '24 at 07:10
  • @Kamal Yes, I tested it too and edited my answer already. Thanks for sharing your observations, very appreciated. – mook765 Oct 26 '24 at 07:13
  • There exists a default /etc/apparmor.d/obsidian rule file that specifies /opt/Obsidian/obsidian as the location of the executable (obsidi*.appimage in our case). Simply moving the downloaded file there solved the issue. This seems to be in keeping with upstream admin policies, and reduces local admin overhead. – superboot Mar 12 '25 at 15:49
25

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,764
  • 3
    Isn't that kind of dangerous to run it this way? – Tomas Greif Apr 30 '24 at 08:26
  • Have the same problem here. This looks like a temporary dangerous solution indeed. Clearly the thing that causes the problem remains. – Daigaku no Baku Jun 13 '24 at 20:37
  • Currently there is a flaw in AppArmor profiles that catch applications like this in SIGTRAP and cause segmentation faults in AppImages that attempt to access permissions (like sandboxing) that they don't have current rights to due to AppArmor issues. This is unfortunately not fixable until someone figures out what's broken in AppArmor profiles. – Thomas Ward Jul 30 '24 at 15:06
  • @TomasGreif et. al. I've put a very large notice on the post as a Moderator Note indicating that this solution has security implications that any user using the solution must accept as their own use of reduced security. Unfortunately until the AppArmor bug is fixed, there's no alternative at this time, and any reduced security risk is upon the user who executes the unsafe execution of the program, and not the poster of this nor Ask Ubuntu. – Thomas Ward Jul 30 '24 at 15:13
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,764
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
  • 739
  • 1
    Please take a look at this answer. – mook765 Sep 25 '24 at 10:22
  • @mook765 I am not sure what you meant by this, and you did not say. This is a known issue in 24.04; I do not want to permanently downgrade my system's security. That's a bad idea. I mentioned that it needed to be done every boot so that the OP would know why it stopped working the next day. – Liam Proven Sep 26 '24 at 11:59
  • 1
    You called it a snag, that's why I thought you might want to prefer a permanent solution. But your idea is correct, it's not a really good thing to do. I use an apparmor profile now, see this answer, this is a permanent solution withoutdowngrading the systems overall security. – mook765 Oct 13 '24 at 18:18
  • Related: https://askubuntu.com/q/1529474/124466 – Archisman Panigrahi Oct 22 '24 at 18:15
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
  • Interestingly enough the appimage is mounted with the nosuid-option already even without this fstab entry. – mook765 Aug 01 '24 at 08:51
-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
  • 599
  • 1
    Your solution disables these restrictions not only for appimages but for any application which is trying to make use of unprivileged namespaces. I would not recommend to do so since we can easily create apparmor profiles for the specific applications we want to use. – mook765 Jan 04 '25 at 07:34
-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
  • 171
  • 1
    An executable owned by root with the setuid-bit set will run with root-privileges which could be considered a security issue as well. That's why unprivileged usernamespaces have been introduces which are nowadays a security risc too. Also this answer seems to be a shortened copy of this answer, the instructions appear to be incomplete. – mook765 Feb 13 '25 at 14:56